[Mesa-dev] [Bug 76188] EGL_EXT_image_dma_buf_import fd ownership is incorrect
https://bugs.freedesktop.org/show_bug.cgi?id=76188 --- Comment #9 from Pekka Paalanen ppaala...@gmail.com --- (In reply to comment #7) I do see risk in not cherry-picking the fix. If an app uses this extension with unfixed Mesa 10.2, then that app will leak file descriptors. Hmm, isn't it the vice versa though? If an app is written to work on unfixed Mesa (the app is broken), it works on both unfixed and fixed Mesa, but leaks fds on fixed Mesa, because nothing will close the fds given to Mesa. If an app is written to work on fixed Mesa (the app is correct), it will not work on unfixed Mesa, because unfixed Mesa will close the fds behind the app's back. (Assuming the app actually needs to store and use the fds again.) So, concretely, do I have to send a copy of the patch to mesa-stable@ or something, or is it already taken care of? Any tag lines to add to the patch? -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 17/20] i965: Preserve CFG when deleting dead control flow.
On Wed, Aug 20, 2014 at 01:58:24PM -0700, Matt Turner wrote: On Tue, Aug 19, 2014 at 12:36 PM, Pohjolainen, Topi topi.pohjolai...@intel.com wrote: On Tue, Aug 19, 2014 at 12:03:01PM -0700, Matt Turner wrote: By the way, I committed the first 6 patches of the series (the one touching the generators had started to rot). I think other than 16 and 17, the only ones missing review are the patches that add the insertion and removal methods. I sent new versions of them based on your feedback a few days ago. Oh, so sorry Matt, I somehow forgot to send my r-b, they are just fine. To make sure I didn't misunderstand: patches 10 and 11 are R-b, or 10, 11, 16, and 17? I didn't want to slap your R-b on something that wasn't reviewed yet. :) Right, I actually meant 10 and 11, but with your fixes to 16 and 17 the entire series has my R-b. Nice work! ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] dri/radeon: drop obsolete radeon_{dri, macros}.h headers
This series is Reviewed-by: Michel Dänzer michel.daen...@amd.com Good riddance! :) -- 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
Re: [Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa
On 21 August 2014 04:56, Michel Dänzer mic...@daenzer.net wrote: On 21.08.2014 04:29, Henri Verbeet wrote: For whatever it's worth, I have been avoiding radeonsi in part because of the LLVM dependency. Some of the other issues already mentioned aside, I also think it makes it just painful to do bisects over moderate/longer periods of time. More painful, sure, but not too bad IME. In particular, if you know the regression is in Mesa, you can always use a stable release of LLVM for the bisect. You only need to change the --with-llvm-prefix= parameter to Mesa's configure for that. Of course, it could still be mildly painful if you need to go so far back that the current stable LLVM release wasn't supported yet. But how often does that happen? Very rarely for me. Sure, it's not impossible, but is that really the kind of process you want users to go through when bisecting a regression? Perhaps throw in building 32-bit versions of both Mesa and LLVM on 64-bit as well if they want to run 32-bit applications. Without LLVM, I'm not sure there would be a driver you could avoid. :) R600g didn't really exist either, and that one seems to have worked out fine. I think in a large part because of work done by Jerome and Dave in the early days, but regardless. From what I've seen from SI, I don't think radeonsi needed to be a separate driver to start with, and while its ISA is certainly different from R600-Cayman, it doesn't particularly strike me as much harder to work with. Back to the more immediate topic though, I think think that on occasion the discussion is framed as Is there any reason using LLVM IR wouldn't work?, while it would perhaps be more appropriate to think of as Would using LLVM IR provide enough advantages to justify adding a LLVM dependency to core Mesa?. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Build fail in clover
Haven't had time to find what caused this, it does seem to be mesa -
Updated mesa last night from a day or two old, llvm 5-10 days old
previous mesa built OK against that.
Got the build fail, updated llvm retried - same fail.
Going back in mesa and applying the build fix for current llvm doesn't
find me a working - ran out of time :-)
./autogen.sh --prefix=/usr --sysconfdir=/etc --enable-texture-float
--with-egl-platforms=x11,drm --with-gallium-drivers=radeonsi,swrast
--enable-opencl --enable-gbm --enable-shared-glapi --enable-glx-tls
--with-dri-drivers= make -j5
Making all in state_trackers/clover
make[3]: Entering directory
'/mnt/sdb1/Src64/Mesa-git/mesa/src/gallium/state_trackers/clover'
CXX llvm/libclllvm_la-invocation.lo
llvm/invocation.cpp: In function 'llvm::Module*
{anonymous}::compile(llvm::LLVMContext, const string, const string,
const string, const string, const string, unsigned int ()[6],
clover::compat::string)':
llvm/invocation.cpp:237:29: error: cannot convert
'std::unique_ptrllvm::Module' to 'llvm::Module*' in return
return act.takeModule();
^
llvm/invocation.cpp:238:4: warning: control reaches end of non-void
function [-Wreturn-type]
}
^
Makefile:834: recipe for target 'llvm/libclllvm_la-invocation.lo' failed
make[3]: *** [llvm/libclllvm_la-invocation.lo] Error 1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Build fail in clover
On 21.08.2014 18:10, Andy Furniss wrote:
Haven't had time to find what caused this, it does seem to be mesa -
Updated mesa last night from a day or two old, llvm 5-10 days old
previous mesa built OK against that.
Got the build fail, updated llvm retried - same fail.
Going back in mesa and applying the build fix for current llvm doesn't
find me a working - ran out of time :-)
./autogen.sh --prefix=/usr --sysconfdir=/etc --enable-texture-float
--with-egl-platforms=x11,drm --with-gallium-drivers=radeonsi,swrast
--enable-opencl --enable-gbm --enable-shared-glapi --enable-glx-tls
--with-dri-drivers= make -j5
Making all in state_trackers/clover
make[3]: Entering directory
'/mnt/sdb1/Src64/Mesa-git/mesa/src/gallium/state_trackers/clover'
CXX llvm/libclllvm_la-invocation.lo
llvm/invocation.cpp: In function 'llvm::Module*
{anonymous}::compile(llvm::LLVMContext, const string, const string,
const string, const string, const string, unsigned int ()[6],
clover::compat::string)':
llvm/invocation.cpp:237:29: error: cannot convert
'std::unique_ptrllvm::Module' to 'llvm::Module*' in return
return act.takeModule();
^
llvm/invocation.cpp:238:4: warning: control reaches end of non-void
function [-Wreturn-type]
}
^
Makefile:834: recipe for target 'llvm/libclllvm_la-invocation.lo' failed
make[3]: *** [llvm/libclllvm_la-invocation.lo] Error 1
See the thread starting at
http://lists.freedesktop.org/archives/mesa-dev/2014-August/066243.html .
--
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 1/2] 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 ystree...@gmail.com
---
src/egl/main/eglcontext.c | 50 ++
src/mesa/drivers/dri/common/dri_util.c | 17
2 files changed, 44 insertions(+), 23 deletions(-)
diff --git a/src/egl/main/eglcontext.c b/src/egl/main/eglcontext.c
index 514b91a..8fe006f 100644
--- a/src/egl/main/eglcontext.c
+++ b/src/egl/main/eglcontext.c
@@ -121,12 +121,50 @@ _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 debug context 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 forward-compatible
+ * context will be created. Forward-compatible contexts are
+ * defined only for OpenGL versions 3.0 and later. They must not
+ * support functionality marked as deprecated 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 robust buffer
+ * access 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 (api != EGL_OPENGL_API
+ !dpy-Extensions.EXT_create_context_robustness) {
err = EGL_BAD_ATTRIBUTE;
break;
}
@@ -194,7 +232,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 2/2] glapi: add function pointers for KHR_debug for gles
Signed-off-by: Matthew Waters ystree...@gmail.com
---
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..7376850 100644
--- a/src/mapi/glapi/gen/KHR_debug.xml
+++ b/src/mapi/glapi/gen/KHR_debug.xml
@@ -145,6 +145,79 @@
param name=label type=GLchar */
/function
+ !-- ES extension has different suffixes --
+ function name=DebugMessageControlKHR alias=DebugMessageControl
offset=assign es1=1.0 es2=2.0
+param name=source type=GLenum/
+param name=type type=GLenum/
+param name=severity type=GLenum/
+param name=count type=GLsizei counter=true/
+param name=ids type=const GLuint * count=count/
+param name=enabled type=GLboolean/
+ /function
+
+ function name=DebugMessageInsertKHR alias=DebugMessageInsert
offset=assign es1=1.0 es2=2.0
+param name=source type=GLenum/
+param name=type type=GLenum/
+param name=id type=GLuint/
+param name=severity type=GLenum/
+param name=length type=GLsizei/
+param name=buf type=const GLchar */
+ /function
+
+ function name=DebugMessageCallbackKHR alias=DebugMessageCallback
offset=assign es1=1.0 es2=2.0
+param name=callback type=GLDEBUGPROC/
+param name=userParam type=const GLvoid */
+ /function
+
+ function name=GetDebugMessageLogKHR alias=GetDebugMessageLog
offset=assign es1=1.0 es2=2.0
+return type=GLuint/
+param name=count type=GLuint/
+param name=bufsize type=GLsizei/
+param name=sources type=GLenum * output=true/
+param name=types type=GLenum * output=true/
+param name=ids type=GLuint * output=true/
+param name=severities type=GLenum * output=true/
+param name=lengths type=GLsizei * output=true/
+param name=messageLog type=GLchar * output=true/
+ /function
+
+ function name=PushDebugGroupKHR alias=PushDebugGroup offset=assign
es1=1.0 es2=2.0
+param name=source type=GLenum/
+param name=id type=GLuint/
+param name=length type=GLsizei/
+param name=message type=const GLchar */
+ /function
+
+ function name=PopDebugGroupKHR alias=PopDebugGroup offset=assign
es1=1.0 es2=2.0/
+
+ function name=ObjectLabelKHR alias=ObjectLabel offset=assign
es1=1.0 es2=2.0
+param name=identifier type=GLenum/
+param name=name type=GLuint/
+param name=length type=GLsizei/
+param name=label type=const GLchar */
+ /function
+
+ function name=GetObjectLabelKHR alias=GetObjectLabel offset=assign
es1=1.0 es2=2.0
+param name=identifier type=GLenum/
+param name=name type=GLuint/
+param name=bufSize type=GLsizei/
+param name=length type=GLsizei */
+param name=label type=GLchar */
+ /function
+
+ function name=ObjectPtrLabelKHR alias=ObjectPtrLabel offset=assign
es1=1.0 es2=2.0
+param name=ptr type=const GLvoid */
+param name=length type=GLsizei/
+param name=label type=const GLchar */
+ /function
+
+ function name=GetObjectPtrLabelKHR alias=GetObjectPtrLabel
offset=assign es1=1.0 es2=2.0
+param name=ptr type=const GLvoid */
+param name=bufSize type=GLsizei/
+param name=length type=GLsizei */
+param name=label type=GLchar */
+ /function
+
/category
/OpenGLAPI
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 },
+ {
[Mesa-dev] [PATCH 0/2] add KHR_debug for gles contexts
Matthew Waters (2): egl: rework handling EGL_CONTEXT_FLAGS for ES debug contexts glapi: add function pointers for KHR_debug for gles src/egl/main/eglcontext.c | 50 +++--- 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/tests/dispatch_sanity.cpp | 25 +++ 5 files changed, 143 insertions(+), 24 deletions(-) -- 2.1.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2] kms-swrast: PRIME and missing defines
Hi Thank you for the review! I will send an updated version asap. On Wed, Aug 20, 2014 at 4:50 PM, Emil Velikov emil.l.veli...@gmail.com wrote: Do you have any rough numbers about the benefit this brings us ? I doubt that there is a big timing impact between sharing named drm handles and prime fds, but yeah right now neither is supported. And we need that for mir and wayland. I believe dma_bufs are the nicest way to share buffers across processes., so I added them first and made sure they work on qxl. I still wanted to do a test run with wayland on qxl, so far I only verified that mir works. Additionally I think that we could get rid of the 'can_share_buffers' logic here and there, since the generic flink - ioctl comes with gem and is hence supported by the interesting 'software'-drm drivers like udl. But right now I was hunting down some graphical artifacts in swrast. regards Andreas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] clover: unsure compat::string is \0 terminated
Le 2014-08-20 16:03, Francisco Jerez a écrit :
EdB e...@sigluy.net writes:
Each time you call c_str() it will grow up, may be you could check if
the string is already \0 terminated before adding it.
Nope, that's not how it works. Every time c_str() is called the size
of
the underlying array is forced to at least size-of-the-actual-string +
1, so nothing will happen if the array is already big enough.
Sure, but I don't think people will reserve this extra capacity.
especially if they use the char* and the std::sting constructor.
I thinks c_str will (should) mostly be use for debug purpose,
they won't change capacity before displaying the string.
The way we do it, we use twice the memory every time a vector capacity
increase (before freeing the old vec) as we don't use a realloc.
I understand c_str() should be use for debug only purpose, but may be
it
could be a problem while debugging huge strings.
Or we can keep compat::string the same and remove c_str(). If someone
needed it, he could use std::string operator and c_str() on it.
At the end, the memory used is the same.
Le 2014-08-18 14:35, Francisco Jerez a écrit :
EdB edb+m...@sigluy.net writes:
otherwise c_str() is not safe
---
src/gallium/state_trackers/clover/util/compat.hpp | 54
---
1 file changed, 48 insertions(+), 6 deletions(-)
diff --git a/src/gallium/state_trackers/clover/util/compat.hpp
b/src/gallium/state_trackers/clover/util/compat.hpp
index 6f0f7cc..7ca1f85 100644
--- a/src/gallium/state_trackers/clover/util/compat.hpp
+++ b/src/gallium/state_trackers/clover/util/compat.hpp
@@ -197,7 +197,7 @@ namespace clover {
return _p[i];
}
- private:
+ protected:
iterator _p; //memory array
size_type _s; //size
size_type _c; //capacity
@@ -306,18 +306,56 @@ namespace clover {
class string : public vectorchar {
public:
- string() : vector() {
+ string() : vector(0, 1) {
+_p[_s - 1] = '\0';
}
- string(const char *p) : vector(p, std::strlen(p)) {
+ string(const char *p) : vector(p, std::strlen(p) + 1) {
+_p[_s - 1] = '\0';
}
templatetypename C
- string(const C v) : vector(v) {
+ string(const C v) : vector(*v.begin(), v.size() + 1) {
+_p[_s - 1] = '\0';
}
- operator std::string() const {
-return std::string(begin(), end());
+ void
+ reserve(size_type m) {
+vector::reserve(m + 1);
+ }
+
+ void
+ resize(size_type m, char x = '\0') {
+vector::resize(m + 1, x);
+_p[_s - 1] = '\0';
+ }
+
+ void
+ push_back(char x) {
+reserve(_s + 1);
+_p[_s - 1] = x;
+_p[_s] = '\0';
+++_s;
+ }
+
+ size_type
+ size() const {
+return _s - 1;
+ }
+
+ size_type
+ capacity() const {
+return _c - 1;
+ }
+
+ iterator
+ end() {
+return _p + size();
+ }
+
+ const_iterator
+ end() const {
+return _p + size();
}
At this point where all methods from the base class need to be
redefined
it probably stops making sense to use inheritance instead of
aggregation. Once we've done that fixing c_str() gets a lot easier
(two
lines of code) because we can just declare the container as mutable
and
fix up the NULL terminator when c_str() is called. Both changes
attached.
const char *
@@ -325,6 +363,10 @@ namespace clover {
return begin();
}
+ operator std::string() const {
+return std::string(begin(), end());
+ }
+
const char *
find(const string s) const {
for (size_t i = 0; i + s.size() size(); ++i) {
--
2.0.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
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/clover: Fix build against LLVM SVN = r215967 v2
From: Michel Dänzer michel.daen...@amd.com
v2: Tom Stellard
- Properly destroy the Module
---
src/gallium/state_trackers/clover/llvm/invocation.cpp | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
b/src/gallium/state_trackers/clover/llvm/invocation.cpp
index 5d2efc4..d351bc5 100644
--- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
+++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
@@ -234,7 +234,11 @@ namespace {
memcpy(address_spaces, c.getTarget().getAddressSpaceMap(),
sizeof(address_spaces));
+#if HAVE_LLVM = 0x0306
+ return act.takeModule().release();
+#else
return act.takeModule();
+#endif
}
void
@@ -415,13 +419,21 @@ clover::compile_program_llvm(const compat::string source,
internalize_functions(mod, kernels);
+ module m;
// Build the clover::module
switch (ir) {
case PIPE_SHADER_IR_TGSI:
//XXX: Handle TGSI
assert(0);
- return module();
+ m = module();
+ break;
default:
- return build_module_llvm(mod, kernels, address_spaces);
+ m = build_module_llvm(mod, kernels, address_spaces);
+ break;
}
+#if HAVE_LLVM = 0x0306
+ // LLVM 3.6 and newer, the user takes ownership of the module.
+ delete mod;
+#endif
+ return m;
}
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa/{version, getstring}: Future-proof version handling
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/mesa/main/getstring.c | 6 ++
src/mesa/main/version.c | 140 +-
2 files changed, 143 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/getstring.c b/src/mesa/main/getstring.c
index 431d60b..f9d13a7 100644
--- a/src/mesa/main/getstring.c
+++ b/src/mesa/main/getstring.c
@@ -58,6 +58,12 @@ shading_language_version(struct gl_context *ctx)
return (const GLubyte *) 4.10;
case 420:
return (const GLubyte *) 4.20;
+ case 430:
+ return (const GLubyte *) 4.30;
+ case 440:
+ return (const GLubyte *) 4.40;
+ case 450:
+ return (const GLubyte *) 4.50;
default:
_mesa_problem(ctx,
Invalid GLSL version in shading_language_version());
diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index 4dea530..c7a2381 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -290,7 +290,122 @@ compute_version(const struct gl_extensions *extensions,
extensions-EXT_texture_swizzle);
/* ARB_sampler_objects is always enabled in mesa
*/
- if (ver_3_3) {
+ const GLboolean ver_4_0 = (ver_3_3
+ consts-GLSLVersion = 400
+ extensions-ARB_draw_buffers_blend
+ extensions-ARB_draw_indirect
+ extensions-ARB_gpu_shader5
+ false // ARB_gpu_shader_fp64
+ extensions-ARB_sample_shading
+ false // ARB_shader_subroutine
+ false // ARB_tesselation_shader
+ extensions-ARB_texture_buffer_object_rgb32
+ extensions-ARB_texture_cube_map_array
+ extensions-ARB_texture_gather
+ extensions-ARB_texture_query_lod
+ extensions-ARB_transform_feedback2
+ extensions-ARB_transform_feedback3);
+
+ const GLboolean ver_4_1 = (ver_4_0
+ consts-GLSLVersion = 410
+ extensions-ARB_ES2_compatibility
+ false // ARB_shader_precision
+ false // ARB_vertex_attrib_64bit
+ extensions-ARB_viewport_array);
+ /* ARB_get_program_binary and
+ ARB_separate_shader_objects are always
enabled in mesa */
+
+ const GLboolean ver_4_2 = (ver_4_1
+ consts-GLSLVersion = 420
+ extensions-ARB_texture_compression_bptc
+ extensions-ARB_shader_atomic_counters
+ extensions-ARB_transform_feedback_instanced
+ extensions-ARB_base_instance
+ extensions-ARB_shader_image_load_store
+ extensions-ARB_conservative_depth
+ extensions-ARB_shading_language_420pack
+ extensions-ARB_internalformat_query);
+ /* ARB_compressed_texture_pixel_storage,
+ ARB_texture_storage and
+ ARB_map_buffer_alignment are always enabled
in mesa */
+
+ const GLboolean ver_4_3 = (ver_4_2
+ consts-GLSLVersion = 430
+ false // ARB_arrays_of_arrays
+ extensions-ARB_ES3_compatibility
+ extensions-ARB_compute_shader
+ extensions-ARB_copy_image
+ extensions-ARB_explicit_uniform_location
+ extensions-ARB_fragment_layer_viewport
+ false // ARB_framebuffer_no_attachments
+ false // ARB_internalformat_query2
+ extensions-ARB_draw_indirect
+ false // ARB_program_interface_query
+ false // ARB_robust_buffer_access_behavior
+ false // ARB_shader_image_size
+ false // ARB_shader_storage_buffer_object
+ extensions-ARB_stencil_texturing
+ extensions-ARB_texture_buffer_range
+ extensions-ARB_texture_query_levels
+ extensions-ARB_texture_multisample
+ extensions-ARB_texture_view);
+ /* ARB_clear_buffer_object,
+ KHR_debug,
+
Re: [Mesa-dev] [PATCH] st/clover: Fix build against LLVM SVN = r215967 v2
Tom Stellard thomas.stell...@amd.com writes:
From: Michel Dänzer michel.daen...@amd.com
v2: Tom Stellard
- Properly destroy the Module
Thanks,
Reviewed-by: Francisco Jerez curroje...@riseup.net
---
src/gallium/state_trackers/clover/llvm/invocation.cpp | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
b/src/gallium/state_trackers/clover/llvm/invocation.cpp
index 5d2efc4..d351bc5 100644
--- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
+++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
@@ -234,7 +234,11 @@ namespace {
memcpy(address_spaces, c.getTarget().getAddressSpaceMap(),
sizeof(address_spaces));
+#if HAVE_LLVM = 0x0306
+ return act.takeModule().release();
+#else
return act.takeModule();
+#endif
}
void
@@ -415,13 +419,21 @@ clover::compile_program_llvm(const compat::string
source,
internalize_functions(mod, kernels);
+ module m;
// Build the clover::module
switch (ir) {
case PIPE_SHADER_IR_TGSI:
//XXX: Handle TGSI
assert(0);
- return module();
+ m = module();
+ break;
default:
- return build_module_llvm(mod, kernels, address_spaces);
+ m = build_module_llvm(mod, kernels, address_spaces);
+ break;
}
+#if HAVE_LLVM = 0x0306
+ // LLVM 3.6 and newer, the user takes ownership of the module.
+ delete mod;
+#endif
+ return m;
}
--
1.8.5.5
pgpkEE9Up7FEi.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/clover: Fix build against LLVM SVN = r215967 v2
On Thu, Aug 21, 2014 at 6:46 AM, Tom Stellard thomas.stell...@amd.com wrote:
From: Michel Dänzer michel.daen...@amd.com
v2: Tom Stellard
- Properly destroy the Module
---
src/gallium/state_trackers/clover/llvm/invocation.cpp | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
b/src/gallium/state_trackers/clover/llvm/invocation.cpp
index 5d2efc4..d351bc5 100644
--- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
+++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
@@ -234,7 +234,11 @@ namespace {
memcpy(address_spaces, c.getTarget().getAddressSpaceMap(),
sizeof(address_spaces));
+#if HAVE_LLVM = 0x0306
+ return act.takeModule().release();
+#else
return act.takeModule();
+#endif
}
void
@@ -415,13 +419,21 @@ clover::compile_program_llvm(const compat::string
source,
internalize_functions(mod, kernels);
+ module m;
// Build the clover::module
switch (ir) {
case PIPE_SHADER_IR_TGSI:
//XXX: Handle TGSI
assert(0);
- return module();
+ m = module();
+ break;
default:
- return build_module_llvm(mod, kernels, address_spaces);
+ m = build_module_llvm(mod, kernels, address_spaces);
+ break;
}
+#if HAVE_LLVM = 0x0306
+ // LLVM 3.6 and newer, the user takes ownership of the module.
+ delete mod;
+#endif
+ return m;
}
This is tested-by: Aaron Watry awa...@gmail.com
It's basically one line different from a patch I was going to send
last night before I ran out of time The only thing that I was
still trying to track down was this possible leak in valgrind that I
was not sure if this patch caused or if it was a pre-existing issue:
Command:
valgrind --leak-check=full ~/src/piglit/bin/cl-program-tester
~/src/piglit/tests/cl/program/execute/vload-int.cl
==15596== 55 bytes in 1 blocks are possibly lost in loss record 182 of 355
==15596==at 0x4C2B0E0: operator new(unsigned long) (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==15596==by 0xC4A53B8: std::string::_Rep::_S_create(unsigned long,
unsigned long, std::allocatorchar const) (in
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
==15596==by 0xBAB1339:
llvm::TimerGroup::TimerGroup(llvm::StringRef) (in
/usr/local/lib/libLLVM-3.6svn.so)
==15596==by 0xBAB170F: llvm::Timer::init(llvm::StringRef) (in
/usr/local/lib/libLLVM-3.6svn.so)
==15596==by 0x9CEC0B2:
clang::CodeGenAction::CreateASTConsumer(clang::CompilerInstance,
llvm::StringRef) (in /usr/local/lib/libMesaOpenCL.so.1.0.0)
==15596==by 0x9BF6D1E:
clang::FrontendAction::CreateWrappedASTConsumer(clang::CompilerInstance,
llvm::StringRef) (in /usr/local/lib/libMesaOpenCL.so.1.0.0)
==15596==by 0x9BF7BD4:
clang::FrontendAction::BeginSourceFile(clang::CompilerInstance,
clang::FrontendInputFile const) (in
/usr/local/lib/libMesaOpenCL.so.1.0.0)
==15596==by 0x9BD82BF:
clang::CompilerInstance::ExecuteAction(clang::FrontendAction) (in
/usr/local/lib/libMesaOpenCL.so.1.0.0)
==15596==by 0x9B89E71: (anonymous
namespace)::compile(llvm::LLVMContext, std::string const,
std::string const, std::string const, std::string const,
std::string const, unsigned int () [6], clover::compat::string)
(invocation.cpp:227)
==15596==by 0x9B8C9C6:
clover::compile_program_llvm(clover::compat::string const,
pipe_shader_ir, clover::compat::string const, clover::compat::string
const, clover::compat::string) (invocation.cpp:416)
==15596==by 0x9B64600:
clover::program::build(clover::ref_vectorclover::device const, char
const*) (program.cpp:62)
==15596==by 0x9B81F63: clBuildProgram (program.cpp:173)
--Aaron
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/clover: Change platform name from Default to Clover
Signed-off-by: Aaron Watry awa...@gmail.com --- src/gallium/state_trackers/clover/api/platform.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/state_trackers/clover/api/platform.cpp b/src/gallium/state_trackers/clover/api/platform.cpp index 81b0854..cf71593 100644 --- a/src/gallium/state_trackers/clover/api/platform.cpp +++ b/src/gallium/state_trackers/clover/api/platform.cpp @@ -61,7 +61,7 @@ clover::GetPlatformInfo(cl_platform_id d_platform, cl_platform_info param, break; case CL_PLATFORM_NAME: - buf.as_string() = Default; + buf.as_string() = Clover; break; case CL_PLATFORM_VENDOR: -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/clover: Fix build against LLVM SVN = r215967 v2
On Thu, Aug 21, 2014 at 08:20:57AM -0500, Aaron Watry wrote:
On Thu, Aug 21, 2014 at 6:46 AM, Tom Stellard thomas.stell...@amd.com wrote:
From: Michel Dänzer michel.daen...@amd.com
v2: Tom Stellard
- Properly destroy the Module
---
src/gallium/state_trackers/clover/llvm/invocation.cpp | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
b/src/gallium/state_trackers/clover/llvm/invocation.cpp
index 5d2efc4..d351bc5 100644
--- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
+++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
@@ -234,7 +234,11 @@ namespace {
memcpy(address_spaces, c.getTarget().getAddressSpaceMap(),
sizeof(address_spaces));
+#if HAVE_LLVM = 0x0306
+ return act.takeModule().release();
+#else
return act.takeModule();
+#endif
}
void
@@ -415,13 +419,21 @@ clover::compile_program_llvm(const compat::string
source,
internalize_functions(mod, kernels);
+ module m;
// Build the clover::module
switch (ir) {
case PIPE_SHADER_IR_TGSI:
//XXX: Handle TGSI
assert(0);
- return module();
+ m = module();
+ break;
default:
- return build_module_llvm(mod, kernels, address_spaces);
+ m = build_module_llvm(mod, kernels, address_spaces);
+ break;
}
+#if HAVE_LLVM = 0x0306
+ // LLVM 3.6 and newer, the user takes ownership of the module.
+ delete mod;
+#endif
+ return m;
}
This is tested-by: Aaron Watry awa...@gmail.com
It's basically one line different from a patch I was going to send
last night before I ran out of time The only thing that I was
still trying to track down was this possible leak in valgrind that I
was not sure if this patch caused or if it was a pre-existing issue:
Command:
valgrind --leak-check=full ~/src/piglit/bin/cl-program-tester
~/src/piglit/tests/cl/program/execute/vload-int.cl
There is a similar valgrind error that shows up in bug in
https://bugs.freedesktop.org/show_bug.cgi?id=81837
which was filed a few weeks ago. See
https://bugs.freedesktop.org/attachment.cgi?id=104338
-Tom
==15596== 55 bytes in 1 blocks are possibly lost in loss record 182 of 355
==15596==at 0x4C2B0E0: operator new(unsigned long) (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==15596==by 0xC4A53B8: std::string::_Rep::_S_create(unsigned long,
unsigned long, std::allocatorchar const) (in
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
==15596==by 0xBAB1339:
llvm::TimerGroup::TimerGroup(llvm::StringRef) (in
/usr/local/lib/libLLVM-3.6svn.so)
==15596==by 0xBAB170F: llvm::Timer::init(llvm::StringRef) (in
/usr/local/lib/libLLVM-3.6svn.so)
==15596==by 0x9CEC0B2:
clang::CodeGenAction::CreateASTConsumer(clang::CompilerInstance,
llvm::StringRef) (in /usr/local/lib/libMesaOpenCL.so.1.0.0)
==15596==by 0x9BF6D1E:
clang::FrontendAction::CreateWrappedASTConsumer(clang::CompilerInstance,
llvm::StringRef) (in /usr/local/lib/libMesaOpenCL.so.1.0.0)
==15596==by 0x9BF7BD4:
clang::FrontendAction::BeginSourceFile(clang::CompilerInstance,
clang::FrontendInputFile const) (in
/usr/local/lib/libMesaOpenCL.so.1.0.0)
==15596==by 0x9BD82BF:
clang::CompilerInstance::ExecuteAction(clang::FrontendAction) (in
/usr/local/lib/libMesaOpenCL.so.1.0.0)
==15596==by 0x9B89E71: (anonymous
namespace)::compile(llvm::LLVMContext, std::string const,
std::string const, std::string const, std::string const,
std::string const, unsigned int () [6], clover::compat::string)
(invocation.cpp:227)
==15596==by 0x9B8C9C6:
clover::compile_program_llvm(clover::compat::string const,
pipe_shader_ir, clover::compat::string const, clover::compat::string
const, clover::compat::string) (invocation.cpp:416)
==15596==by 0x9B64600:
clover::program::build(clover::ref_vectorclover::device const, char
const*) (program.cpp:62)
==15596==by 0x9B81F63: clBuildProgram (program.cpp:173)
--Aaron
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/clover: Fix build against LLVM SVN = r215967 v2
In that case, feel free to upgrade to a
Reviewed-by: Aaron Watry awa...@gmail.com
On Thu, Aug 21, 2014 at 8:25 AM, Tom Stellard t...@stellard.net wrote:
On Thu, Aug 21, 2014 at 08:20:57AM -0500, Aaron Watry wrote:
On Thu, Aug 21, 2014 at 6:46 AM, Tom Stellard thomas.stell...@amd.com
wrote:
From: Michel Dänzer michel.daen...@amd.com
v2: Tom Stellard
- Properly destroy the Module
---
src/gallium/state_trackers/clover/llvm/invocation.cpp | 16
++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
b/src/gallium/state_trackers/clover/llvm/invocation.cpp
index 5d2efc4..d351bc5 100644
--- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
+++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
@@ -234,7 +234,11 @@ namespace {
memcpy(address_spaces, c.getTarget().getAddressSpaceMap(),
sizeof(address_spaces));
+#if HAVE_LLVM = 0x0306
+ return act.takeModule().release();
+#else
return act.takeModule();
+#endif
}
void
@@ -415,13 +419,21 @@ clover::compile_program_llvm(const compat::string
source,
internalize_functions(mod, kernels);
+ module m;
// Build the clover::module
switch (ir) {
case PIPE_SHADER_IR_TGSI:
//XXX: Handle TGSI
assert(0);
- return module();
+ m = module();
+ break;
default:
- return build_module_llvm(mod, kernels, address_spaces);
+ m = build_module_llvm(mod, kernels, address_spaces);
+ break;
}
+#if HAVE_LLVM = 0x0306
+ // LLVM 3.6 and newer, the user takes ownership of the module.
+ delete mod;
+#endif
+ return m;
}
This is tested-by: Aaron Watry awa...@gmail.com
It's basically one line different from a patch I was going to send
last night before I ran out of time The only thing that I was
still trying to track down was this possible leak in valgrind that I
was not sure if this patch caused or if it was a pre-existing issue:
Command:
valgrind --leak-check=full ~/src/piglit/bin/cl-program-tester
~/src/piglit/tests/cl/program/execute/vload-int.cl
There is a similar valgrind error that shows up in bug in
https://bugs.freedesktop.org/show_bug.cgi?id=81837
which was filed a few weeks ago. See
https://bugs.freedesktop.org/attachment.cgi?id=104338
-Tom
==15596== 55 bytes in 1 blocks are possibly lost in loss record 182 of 355
==15596==at 0x4C2B0E0: operator new(unsigned long) (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==15596==by 0xC4A53B8: std::string::_Rep::_S_create(unsigned long,
unsigned long, std::allocatorchar const) (in
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
==15596==by 0xBAB1339:
llvm::TimerGroup::TimerGroup(llvm::StringRef) (in
/usr/local/lib/libLLVM-3.6svn.so)
==15596==by 0xBAB170F: llvm::Timer::init(llvm::StringRef) (in
/usr/local/lib/libLLVM-3.6svn.so)
==15596==by 0x9CEC0B2:
clang::CodeGenAction::CreateASTConsumer(clang::CompilerInstance,
llvm::StringRef) (in /usr/local/lib/libMesaOpenCL.so.1.0.0)
==15596==by 0x9BF6D1E:
clang::FrontendAction::CreateWrappedASTConsumer(clang::CompilerInstance,
llvm::StringRef) (in /usr/local/lib/libMesaOpenCL.so.1.0.0)
==15596==by 0x9BF7BD4:
clang::FrontendAction::BeginSourceFile(clang::CompilerInstance,
clang::FrontendInputFile const) (in
/usr/local/lib/libMesaOpenCL.so.1.0.0)
==15596==by 0x9BD82BF:
clang::CompilerInstance::ExecuteAction(clang::FrontendAction) (in
/usr/local/lib/libMesaOpenCL.so.1.0.0)
==15596==by 0x9B89E71: (anonymous
namespace)::compile(llvm::LLVMContext, std::string const,
std::string const, std::string const, std::string const,
std::string const, unsigned int () [6], clover::compat::string)
(invocation.cpp:227)
==15596==by 0x9B8C9C6:
clover::compile_program_llvm(clover::compat::string const,
pipe_shader_ir, clover::compat::string const, clover::compat::string
const, clover::compat::string) (invocation.cpp:416)
==15596==by 0x9B64600:
clover::program::build(clover::ref_vectorclover::device const, char
const*) (program.cpp:62)
==15596==by 0x9B81F63: clBuildProgram (program.cpp:173)
--Aaron
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] r600g: Fix flat/smooth shade state toggle
Pushed, thanks.
Marek
On Wed, Aug 20, 2014 at 9:55 PM, Glenn Kennard glenn.kenn...@gmail.com wrote:
If only the flat/smooth shade state changed between
two render calls the prior code would miss updating the
hardware state.
Also add check for sprite coord, potentially same type
of issue otherwise for it.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81967
Signed-off-by: Glenn Kennard glenn.kenn...@gmail.com
---
V2:
- No new shader variant created
- Also check for sprite coord enable since its state is updated
in similar fashion to flatshade.
src/gallium/drivers/r600/r600_state_common.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/r600_state_common.c
b/src/gallium/drivers/r600/r600_state_common.c
index 7594d0e..028d800 100644
--- a/src/gallium/drivers/r600/r600_state_common.c
+++ b/src/gallium/drivers/r600/r600_state_common.c
@@ -1227,7 +1227,9 @@ static bool r600_update_derived_state(struct
r600_context *rctx)
if (unlikely(!rctx-ps_shader-current))
return false;
- if (unlikely(ps_dirty || rctx-pixel_shader.shader !=
rctx-ps_shader-current)) {
+ if (unlikely(ps_dirty || rctx-pixel_shader.shader !=
rctx-ps_shader-current ||
+ rctx-rasterizer-sprite_coord_enable !=
rctx-ps_shader-current-sprite_coord_enable ||
+ rctx-rasterizer-flatshade !=
rctx-ps_shader-current-flatshade)) {
if (rctx-cb_misc_state.nr_ps_color_outputs !=
rctx-ps_shader-current-nr_ps_color_outputs) {
rctx-cb_misc_state.nr_ps_color_outputs =
rctx-ps_shader-current-nr_ps_color_outputs;
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radeonsi: set DB_DEPTH_SIZE.HEIGHT_TILE_MAX, inline other fields
From: Marek Olšák marek.ol...@amd.com
This fixes rendering to a non-zero layer/face/slice with HTILE.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72685
---
src/gallium/drivers/radeonsi/si_state.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/radeonsi/si_state.c
index 571c487..3467af6 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -1746,7 +1746,8 @@ static void si_init_depth_surface(struct si_context *sctx,
struct si_screen *sscreen = sctx-screen;
struct r600_texture *rtex = (struct r600_texture*)surf-base.texture;
unsigned level = surf-base.u.tex.level;
- unsigned pitch, slice, format, tile_mode_index, array_mode;
+ struct radeon_surface_level *levelinfo = rtex-surface.level[level];
+ unsigned format, tile_mode_index, array_mode;
unsigned macro_aspect, tile_split, stile_split, bankh, bankw, nbanks,
pipe_config;
uint32_t z_info, s_info, db_depth_info;
uint64_t z_offs, s_offs;
@@ -1782,12 +1783,6 @@ static void si_init_depth_surface(struct si_context
*sctx,
z_offs += rtex-surface.level[level].offset;
s_offs += rtex-surface.stencil_level[level].offset;
- pitch = (rtex-surface.level[level].nblk_x / 8) - 1;
- slice = (rtex-surface.level[level].nblk_x *
rtex-surface.level[level].nblk_y) / 64;
- if (slice) {
- slice = slice - 1;
- }
-
db_depth_info = S_02803C_ADDR5_SWIZZLE_MASK(1);
z_info = S_028040_FORMAT(format);
@@ -1876,8 +1871,10 @@ static void si_init_depth_surface(struct si_context
*sctx,
surf-db_stencil_info = s_info;
surf-db_depth_base = z_offs 8;
surf-db_stencil_base = s_offs 8;
- surf-db_depth_size = S_028058_PITCH_TILE_MAX(pitch);
- surf-db_depth_slice = S_02805C_SLICE_TILE_MAX(slice);
+ surf-db_depth_size = S_028058_PITCH_TILE_MAX((levelinfo-nblk_x / 8) -
1) |
+ S_028058_HEIGHT_TILE_MAX((levelinfo-nblk_y / 8)
- 1);
+ surf-db_depth_slice = S_02805C_SLICE_TILE_MAX((levelinfo-nblk_x *
+ levelinfo-nblk_y) / 64
- 1);
surf-db_htile_surface = db_htile_surface;
surf-pa_su_poly_offset_db_fmt_cntl = pa_su_poly_offset_db_fmt_cntl;
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/7] r600g: set DB_DEPTH_SIZE.HEIGHT_TILE_MAX for EG/CM, inline other fields
From: Marek Olšák marek.ol...@amd.com
This fixes rendering to non-zero layer/face/slice with HTILE.
---
src/gallium/drivers/r600/evergreen_state.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_state.c
b/src/gallium/drivers/r600/evergreen_state.c
index 841ad0c..73068ac 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -1166,21 +1166,19 @@ static void evergreen_init_depth_surface(struct
r600_context *rctx,
{
struct r600_screen *rscreen = rctx-screen;
struct r600_texture *rtex = (struct r600_texture*)surf-base.texture;
+ unsigned level = surf-base.u.tex.level;
+ struct radeon_surface_level *levelinfo = rtex-surface.level[level];
uint64_t offset;
- unsigned level, pitch, slice, format, array_mode;
+ unsigned format, array_mode;
unsigned macro_aspect, tile_split, bankh, bankw, nbanks;
- level = surf-base.u.tex.level;
+
format = r600_translate_dbformat(surf-base.format);
assert(format != ~0);
offset = rtex-resource.gpu_address;
offset += rtex-surface.level[level].offset;
- pitch = (rtex-surface.level[level].nblk_x / 8) - 1;
- slice = (rtex-surface.level[level].nblk_x *
rtex-surface.level[level].nblk_y) / 64;
- if (slice) {
- slice = slice - 1;
- }
+
switch (rtex-surface.level[level].mode) {
case RADEON_SURF_MODE_2D:
array_mode = V_028C70_ARRAY_2D_TILED_THIN1;
@@ -1216,8 +1214,10 @@ static void evergreen_init_depth_surface(struct
r600_context *rctx,
surf-db_depth_base = offset;
surf-db_depth_view =
S_028008_SLICE_START(surf-base.u.tex.first_layer) |
S_028008_SLICE_MAX(surf-base.u.tex.last_layer);
- surf-db_depth_size = S_028058_PITCH_TILE_MAX(pitch);
- surf-db_depth_slice = S_02805C_SLICE_TILE_MAX(slice);
+ surf-db_depth_size = S_028058_PITCH_TILE_MAX(levelinfo-nblk_x / 8 -
1) |
+ S_028058_HEIGHT_TILE_MAX(levelinfo-nblk_y / 8 -
1);
+ surf-db_depth_slice = S_02805C_SLICE_TILE_MAX(levelinfo-nblk_x *
+ levelinfo-nblk_y / 64 -
1);
switch (surf-base.format) {
case PIPE_FORMAT_Z24X8_UNORM:
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallium/pb_bufmgr_cache: limit the size of cache
From: Marek Olšák marek.ol...@amd.com
This should make a machine which is running piglit more responsive at times.
e.g. streaming-texture-leak can easily eat 600 MB because of how fast it
creates new textures.
---
src/gallium/auxiliary/pipebuffer/pb_bufmgr.h | 3 ++-
src/gallium/auxiliary/pipebuffer/pb_bufmgr_cache.c | 20 ++--
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 12
src/gallium/winsys/svga/drm/vmw_screen_pools.c | 3 ++-
4 files changed, 30 insertions(+), 8 deletions(-)
diff --git a/src/gallium/auxiliary/pipebuffer/pb_bufmgr.h
b/src/gallium/auxiliary/pipebuffer/pb_bufmgr.h
index d5b0ee2..147ce39 100644
--- a/src/gallium/auxiliary/pipebuffer/pb_bufmgr.h
+++ b/src/gallium/auxiliary/pipebuffer/pb_bufmgr.h
@@ -163,7 +163,8 @@ struct pb_manager *
pb_cache_manager_create(struct pb_manager *provider,
unsigned usecs,
float size_factor,
-unsigned bypass_usage);
+unsigned bypass_usage,
+uint64_t maximum_cache_size);
struct pb_fence_ops;
diff --git a/src/gallium/auxiliary/pipebuffer/pb_bufmgr_cache.c
b/src/gallium/auxiliary/pipebuffer/pb_bufmgr_cache.c
index 32a8875..5eb8d06 100644
--- a/src/gallium/auxiliary/pipebuffer/pb_bufmgr_cache.c
+++ b/src/gallium/auxiliary/pipebuffer/pb_bufmgr_cache.c
@@ -84,6 +84,7 @@ struct pb_cache_manager
pb_size numDelayed;
float size_factor;
unsigned bypass_usage;
+ uint64_t cache_size, max_cache_size;
};
@@ -114,6 +115,7 @@ _pb_cache_buffer_destroy(struct pb_cache_buffer *buf)
LIST_DEL(buf-head);
assert(mgr-numDelayed);
--mgr-numDelayed;
+ mgr-cache_size -= buf-base.size;
assert(!pipe_is_referenced(buf-base.reference));
pb_reference(buf-buffer, NULL);
FREE(buf);
@@ -158,11 +160,20 @@ pb_cache_buffer_destroy(struct pb_buffer *_buf)
assert(!pipe_is_referenced(buf-base.reference));
_pb_cache_buffer_list_check_free(mgr);
-
+
+ /* Directly release any buffer that exceeds the limit. */
+ if (mgr-cache_size + buf-base.size mgr-max_cache_size) {
+ pb_reference(buf-buffer, NULL);
+ FREE(buf);
+ pipe_mutex_unlock(mgr-mutex);
+ return;
+ }
+
buf-start = os_time_get();
buf-end = buf-start + mgr-usecs;
LIST_ADDTAIL(buf-head, mgr-delayed);
++mgr-numDelayed;
+ mgr-cache_size += buf-base.size;
pipe_mutex_unlock(mgr-mutex);
}
@@ -314,6 +325,7 @@ pb_cache_manager_create_buffer(struct pb_manager *_mgr,
}
if(buf) {
+ mgr-cache_size -= buf-base.size;
LIST_DEL(buf-head);
--mgr-numDelayed;
pipe_mutex_unlock(mgr-mutex);
@@ -400,12 +412,15 @@ pb_cache_manager_destroy(struct pb_manager *mgr)
* the requested size as cache hits.
* @param bypass_usage Bitmask. If (requested usage bypass_usage) != 0,
* buffer allocation requests are redirected to the provider.
+ * @param maximum_cache_size Maximum size of all unused buffers the cache can
+ * hold.
*/
struct pb_manager *
pb_cache_manager_create(struct pb_manager *provider,
unsigned usecs,
float size_factor,
-unsigned bypass_usage)
+unsigned bypass_usage,
+uint64_t maximum_cache_size)
{
struct pb_cache_manager *mgr;
@@ -425,6 +440,7 @@ pb_cache_manager_create(struct pb_manager *provider,
mgr-bypass_usage = bypass_usage;
LIST_INITHEAD(mgr-delayed);
mgr-numDelayed = 0;
+ mgr-max_cache_size = maximum_cache_size;
pipe_mutex_init(mgr-mutex);
return mgr-base;
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
index 820cc90..3b695f9 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
@@ -671,16 +671,20 @@ radeon_drm_winsys_create(int fd, radeon_screen_create_t
screen_create)
ws-kman = radeon_bomgr_create(ws);
if (!ws-kman)
goto fail;
-ws-cman_vram = pb_cache_manager_create(ws-kman, 100, 2.0f, 0);
+ws-cman_vram = pb_cache_manager_create(ws-kman, 100, 2.0f, 0,
+ws-info.vram_size / 8);
if (!ws-cman_vram)
goto fail;
-ws-cman_vram_gtt_wc = pb_cache_manager_create(ws-kman, 100, 2.0f, 0);
+ws-cman_vram_gtt_wc = pb_cache_manager_create(ws-kman, 100, 2.0f, 0,
+ ws-info.vram_size / 8);
if (!ws-cman_vram_gtt_wc)
goto fail;
-ws-cman_gtt = pb_cache_manager_create(ws-kman, 100, 2.0f, 0);
+ws-cman_gtt = pb_cache_manager_create(ws-kman, 100, 2.0f, 0,
+ ws-info.gart_size / 8);
if (!ws-cman_gtt)
goto fail;
-ws-cman_gtt_wc = pb_cache_manager_create(ws-kman, 100, 2.0f, 0);
+ws-cman_gtt_wc =
[Mesa-dev] [PATCH 7/7] r600g: set VGT_ENHANCE=4 on R7xx
From: Marek Olšák marek.ol...@amd.com
This is a golden setting on RV740, but there is a hw bug which recommends
setting it on all R7xx chipsets.
---
src/gallium/drivers/r600/r600_state.c | 1 +
src/gallium/drivers/r600/r600d.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/src/gallium/drivers/r600/r600_state.c
b/src/gallium/drivers/r600/r600_state.c
index 454c458..410b66b 100644
--- a/src/gallium/drivers/r600/r600_state.c
+++ b/src/gallium/drivers/r600/r600_state.c
@@ -2277,6 +2277,7 @@ void r600_init_atom_start_cs(struct r600_context *rctx)
r600_store_config_reg(cb, R_009714_VC_ENHANCE, 0);
if (rctx-b.chip_class = R700) {
+ r600_store_context_reg(cb, R_028A50_VGT_ENHANCE, 4);
r600_store_config_reg(cb,
R_008D8C_SQ_DYN_GPR_CNTL_PS_FLUSH_REQ, 0x4000);
r600_store_config_reg(cb, R_009830_DB_DEBUG, 0);
r600_store_config_reg(cb, R_009838_DB_WATERMARKS, 0x00420204);
diff --git a/src/gallium/drivers/r600/r600d.h b/src/gallium/drivers/r600/r600d.h
index 17568ab..3cf7b88 100644
--- a/src/gallium/drivers/r600/r600d.h
+++ b/src/gallium/drivers/r600/r600d.h
@@ -889,6 +889,7 @@
#define S_028A40_CUT_MODE(x) (((x) 0x3) 3)
#define G_028A40_CUT_MODE(x) (((x) 3) 0x3)
#define C_028A40_CUT_MODE0xFFE7
+#define R_028A50_VGT_ENHANCE 0x028A50
#define R_028A6C_VGT_GS_OUT_PRIM_TYPE0x028A6C
#define S_028A6C_OUTPRIM_TYPE(x) (((x) 0x3F) 0)
#define V_028A6C_OUTPRIM_TYPE_POINTLIST0
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/7] r600g: fix layered clear
From: Marek Olšák marek.ol...@amd.com Cc: mesa-sta...@lists.freedesktop.org --- src/gallium/drivers/r600/r600_blit.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/gallium/drivers/r600/r600_blit.c b/src/gallium/drivers/r600/r600_blit.c index 0f43839..f766e37 100644 --- a/src/gallium/drivers/r600/r600_blit.c +++ b/src/gallium/drivers/r600/r600_blit.c @@ -441,7 +441,8 @@ static void r600_clear(struct pipe_context *ctx, unsigned buffers, } r600_blitter_begin(ctx, R600_CLEAR); - util_blitter_clear(rctx-blitter, fb-width, fb-height, 1, + util_blitter_clear(rctx-blitter, fb-width, fb-height, + util_framebuffer_get_num_layers(fb), buffers, color, depth, stencil); r600_blitter_end(ctx); -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/7] r600g: enable fast depth clear for array textures and cubemaps
From: Marek Olšák marek.ol...@amd.com
I have a piglit test that hits this.
---
src/gallium/drivers/r600/r600_blit.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/r600_blit.c
b/src/gallium/drivers/r600/r600_blit.c
index a3cfdae..0f43839 100644
--- a/src/gallium/drivers/r600/r600_blit.c
+++ b/src/gallium/drivers/r600/r600_blit.c
@@ -429,7 +429,8 @@ static void r600_clear(struct pipe_context *ctx, unsigned
buffers,
*/
/* Only use htile for first level */
if (rtex-htile_buffer !level
- util_max_layer(rtex-resource.b.b, level) == 0) {
+ fb-zsbuf-u.tex.first_layer == 0
+ fb-zsbuf-u.tex.last_layer ==
util_max_layer(rtex-resource.b.b, level)) {
if (rtex-depth_clear_value != depth) {
rtex-depth_clear_value = depth;
rctx-db_state.atom.dirty = true;
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/7] r600g: use HTILE allocator from SI
From: Marek Olšák marek.ol...@amd.com
It's almost the same.
This enables tiling for HTILE. It also enables Hyper-Z for other texture
targets (1D, 1D_ARRAY, 2D_ARRAY, CUBE, CUBE_ARRAY, 3D, RECT).
2D array depth textures are tested by Unigine Sanctuary and my new piglit
test.
---
src/gallium/drivers/r600/evergreen_state.c | 5 +--
src/gallium/drivers/r600/r600_state.c | 5 +--
src/gallium/drivers/radeon/r600_texture.c | 60 ++
3 files changed, 23 insertions(+), 47 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_state.c
b/src/gallium/drivers/r600/evergreen_state.c
index 73068ac..30cf32b 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -1266,9 +1266,8 @@ static void evergreen_init_depth_surface(struct
r600_context *rctx,
uint64_t va = rtex-htile_buffer-gpu_address;
surf-db_htile_data_base = va 8;
surf-db_htile_surface = S_028ABC_HTILE_WIDTH(1) |
- S_028ABC_HTILE_HEIGHT(1) |
- S_028ABC_FULL_CACHE(1) |
- S_028ABC_LINEAR(1);
+S_028ABC_HTILE_HEIGHT(1) |
+S_028ABC_FULL_CACHE(1);
surf-db_z_info |= S_028040_TILE_SURFACE_ENABLE(1);
surf-db_preload_control = 0;
}
diff --git a/src/gallium/drivers/r600/r600_state.c
b/src/gallium/drivers/r600/r600_state.c
index 607b199..eb5d8f6 100644
--- a/src/gallium/drivers/r600/r600_state.c
+++ b/src/gallium/drivers/r600/r600_state.c
@@ -1104,9 +1104,8 @@ static void r600_init_depth_surface(struct r600_context
*rctx,
if (rtex-htile_buffer !level) {
surf-db_htile_data_base = 0;
surf-db_htile_surface = S_028D24_HTILE_WIDTH(1) |
- S_028D24_HTILE_HEIGHT(1) |
- S_028D24_FULL_CACHE(1) |
- S_028D24_LINEAR(1);
+S_028D24_HTILE_HEIGHT(1) |
+S_028D24_FULL_CACHE(1);
/* preload is not working properly on r6xx/r7xx */
surf-db_depth_info |= S_028010_TILE_SURFACE_ENABLE(1);
}
diff --git a/src/gallium/drivers/radeon/r600_texture.c
b/src/gallium/drivers/radeon/r600_texture.c
index d07c9a0..17aca01 100644
--- a/src/gallium/drivers/radeon/r600_texture.c
+++ b/src/gallium/drivers/radeon/r600_texture.c
@@ -481,19 +481,34 @@ static void r600_texture_alloc_cmask_separate(struct
r600_common_screen *rscreen
rtex-cb_color_info |= EG_S_028C70_FAST_CLEAR(1);
}
-static unsigned si_texture_htile_alloc_size(struct r600_common_screen *rscreen,
+static unsigned r600_texture_get_htile_size(struct r600_common_screen *rscreen,
struct r600_texture *rtex)
{
unsigned cl_width, cl_height, width, height;
unsigned slice_elements, slice_bytes, pipe_interleave_bytes, base_align;
unsigned num_pipes = rscreen-tiling_info.num_channels;
+ if (rscreen-chip_class = EVERGREEN
+ rscreen-info.drm_minor 26)
+ return 0;
+
+ /* HW bug on R6xx. */
+ if (rscreen-chip_class == R600
+ (rtex-surface.level[0].npix_x 7680 ||
+rtex-surface.level[0].npix_y 7680))
+ return 0;
+
/* HTILE is broken with 1D tiling on old kernels and CIK. */
- if (rtex-surface.level[0].mode == RADEON_SURF_MODE_1D
- rscreen-chip_class = CIK rscreen-info.drm_minor 38)
+ if (rscreen-chip_class = CIK
+ rtex-surface.level[0].mode == RADEON_SURF_MODE_1D
+ rscreen-info.drm_minor 38)
return 0;
switch (num_pipes) {
+ case 1:
+ cl_width = 32;
+ cl_height = 16;
+ break;
case 2:
cl_width = 32;
cl_height = 32;
@@ -528,51 +543,14 @@ static unsigned si_texture_htile_alloc_size(struct
r600_common_screen *rscreen,
align(slice_bytes, base_align);
}
-static unsigned r600_texture_htile_alloc_size(struct r600_common_screen
*rscreen,
- struct r600_texture *rtex)
-{
- unsigned sw = rtex-surface.level[0].nblk_x * rtex-surface.blk_w;
- unsigned sh = rtex-surface.level[0].nblk_y * rtex-surface.blk_h;
- unsigned npipes = rscreen-info.r600_num_tile_pipes;
- unsigned htile_size;
-
- /* XXX also use it for other texture targets */
- if (rscreen-info.drm_minor 26 ||
- rtex-resource.b.b.target != PIPE_TEXTURE_2D ||
- rtex-surface.level[0].nblk_x 32 ||
- rtex-surface.level[0].nblk_y 32) {
- return 0;
- }
-
- /* HW bug on R6xx. */
- if
[Mesa-dev] [PATCH 6/7] r600g: expose AMD_vertex_shader_layer and *_viewport_index on R600-R700
From: Marek Olšák marek.ol...@amd.com already implemented --- src/gallium/drivers/r600/r600_pipe.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/drivers/r600/r600_pipe.c b/src/gallium/drivers/r600/r600_pipe.c index e02c053..c5329e6 100644 --- a/src/gallium/drivers/r600/r600_pipe.c +++ b/src/gallium/drivers/r600/r600_pipe.c @@ -261,6 +261,7 @@ static int r600_get_param(struct pipe_screen* pscreen, enum pipe_cap param) case PIPE_CAP_TEXTURE_MULTISAMPLE: case PIPE_CAP_BUFFER_MAP_PERSISTENT_COHERENT: case PIPE_CAP_TGSI_VS_WINDOW_SPACE_POSITION: + case PIPE_CAP_TGSI_VS_LAYER_VIEWPORT: return 1; case PIPE_CAP_COMPUTE: @@ -301,7 +302,6 @@ static int r600_get_param(struct pipe_screen* pscreen, enum pipe_cap param) /* Supported on Evergreen. */ case PIPE_CAP_SEAMLESS_CUBE_MAP_PER_TEXTURE: case PIPE_CAP_CUBE_MAP_ARRAY: - case PIPE_CAP_TGSI_VS_LAYER_VIEWPORT: case PIPE_CAP_TEXTURE_GATHER_SM5: case PIPE_CAP_TEXTURE_QUERY_LOD: case PIPE_CAP_TGSI_FS_FINE_DERIVATIVE: -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/7] r600g: some DB bug workarounds for R6xx DB flushing
From: Marek Olšák marek.ol...@amd.com
---
src/gallium/drivers/r600/r600_state.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/gallium/drivers/r600/r600_state.c
b/src/gallium/drivers/r600/r600_state.c
index eb5d8f6..454c458 100644
--- a/src/gallium/drivers/r600/r600_state.c
+++ b/src/gallium/drivers/r600/r600_state.c
@@ -1615,6 +1615,13 @@ static void r600_emit_db_misc_state(struct r600_context
*rctx, struct r600_atom
S_028D0C_STENCIL_COPY_ENABLE(a-copy_stencil) |
S_028D0C_COPY_CENTROID(1) |
S_028D0C_COPY_SAMPLE(a-copy_sample);
+
+ if (rctx-b.chip_class == R600)
+ db_render_override |= S_028D10_NOOP_CULL_DISABLE(1);
+
+ if (rctx-b.family == CHIP_RV610 || rctx-b.family ==
CHIP_RV630 ||
+ rctx-b.family == CHIP_RV620 || rctx-b.family ==
CHIP_RV635)
+ db_render_override |=
S_028D10_FORCE_HIZ_ENABLE(V_028D10_FORCE_DISABLE);
} else if (a-flush_depthstencil_in_place) {
db_render_control |= S_028D0C_DEPTH_COMPRESS_DISABLE(1) |
S_028D0C_STENCIL_COMPRESS_DISABLE(1);
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 61416] Clover doesn't authenticate when not run as a privileged user
https://bugs.freedesktop.org/show_bug.cgi?id=61416 Tom Stellard tstel...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Tom Stellard tstel...@gmail.com --- This should work now if you enable rendernodes in the kernel. You can do this by adding drm.rnodes=1 you your kernel command line. The oldest kernel that supports rendernodes is 3.12. Please re-open if you are still having issues. -- 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] Mesa 10.3 release candidate 1
Mesa 10.3 release candidate 1 is now available for testing. The current plan is to have an additional release candidate each Friday until the eventual 10.3 release, (Ian can follow up to state what the planned date is for that). The tag in the git repository for Mesa 10.3-rc1 is 'mesa-10.3-rc1'. I have also pushed a tag '10.3-branchpoint' to mark the point where master and 10.3 diverge. This should make git-describe a bit more useful. As a reminder, with the 10.3 branch now created, patches nominated with: CC: mesa-sta...@lists.freedesktop.org will now be candidates only for the new 10.3 branch. To nominate patches for the older 10.2 branch as well, please use: CC: 10.2 10.3 mesa-sta...@lists.freedesktop.org The expectation is that the 10.2 branch will remain alive with bi-weekly releases until after 10.3.1 release. Mesa 10.3 release candidate 1 is available for download from ftp://freedesktop.org/pub/mesa/10.3 sha256sums: db7b12e65db2443335dceec9c6076b6643ea0ebe93edbb89b0cfa22b2812d5e0 MesaLib-10.3.0-rc1.tar.bz2 8c5fe067942298f623aa4ffa0a542273d02c9051619fc3b4c268e119d07e8a38 MesaLib-10.3.0-rc1.tar.gz 5104228927595f88619cb26e54593e8ba7337f80f6dcd432b915a29bb29e1fdd MesaLib-10.3.0-rc1.zip I have verified building from the .tar.bz2 file by doing the following on a Debian (unstable) system: tar xjf MesaLib-10.3.0-rc1.tar.bz2 cd Mesa-10.3.0-rc1 ./configure --enable-gallium-llvm make -j6 make install -Carl pgphi54nBOUKc.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 66175] R600/SI: SETCC for v2i32/v4i32 triggers LLVM assertion
https://bugs.freedesktop.org/show_bug.cgi?id=66175 Tom Stellard tstel...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Tom Stellard tstel...@gmail.com --- This is working now. -- 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 66931] Can't specify local buffer size using clSetKernelArg
https://bugs.freedesktop.org/show_bug.cgi?id=66931 Tom Stellard tstel...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Tom Stellard tstel...@gmail.com --- This was fixed in git a while ago. commit 4f8048bb5a8558ae4313b12ffd70b593cc629fe8 commit d9576598c7e1c6e4fee913a918345190248a9d19 -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/4] Several memory leak fixes
Compute on evergreen has slowly developed a few more memory leaks (or maybe I had never finished fixing them all before). One of the leaks got in when the memory pool work went in recently, the others seem to have been around for a while. The last patch (aux/pipe_loader) seems to affect more than just CL on r600. After this series, I show a total of 568 bytes definitely leaks when running: piglit/bin/cl-program-tester piglit/tests/cl/program/execute/vload-int.cl Before, the total was ~8-9k. r600/compute: Don't leak compute pool r600g/compute: Don't leak cbufs in compute state r600g/compute: Stop leaking CL kernel bytecode/resources aux/pipe_loader: Don't leak dlerror string on dlopen ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] r600g/compute: Stop leaking CL kernel bytecode/resources
Tested on CEDAR
Signed-off-by: Aaron Watry awa...@gmail.com
---
src/gallium/drivers/r600/evergreen_compute.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/src/gallium/drivers/r600/evergreen_compute.c
index dcb7183..71a9218 100644
--- a/src/gallium/drivers/r600/evergreen_compute.c
+++ b/src/gallium/drivers/r600/evergreen_compute.c
@@ -238,7 +238,18 @@ void evergreen_delete_compute_state(struct pipe_context
*ctx, void* state)
if (!shader)
return;
- FREE(shader-kernels);
+ if (shader-kernels) {
+ for (int i = 0; i shader-num_kernels; i++) {
+ if (shader-kernels[i].code_bo) {
+ pipe_resource_reference(
+ (struct pipe_resource**)
shader-kernels[i].code_bo,
+ NULL
+ );
+ }
+ FREE(shader-kernels[i].bc.bytecode);
+ }
+ FREE(shader-kernels);
+ }
if (shader-ctx){
struct pipe_framebuffer_state *fb_state =
shader-ctx-framebuffer.state;
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] r600/compute: Don't leak compute pool item_list/unallocated_list
Signed-off-by: Aaron Watry awa...@gmail.com --- src/gallium/drivers/r600/compute_memory_pool.c | 4 1 file changed, 4 insertions(+) diff --git a/src/gallium/drivers/r600/compute_memory_pool.c b/src/gallium/drivers/r600/compute_memory_pool.c index 9324b84..55ff7d5 100644 --- a/src/gallium/drivers/r600/compute_memory_pool.c +++ b/src/gallium/drivers/r600/compute_memory_pool.c @@ -95,6 +95,10 @@ void compute_memory_pool_delete(struct compute_memory_pool* pool) pool-screen-b.b.resource_destroy((struct pipe_screen *) pool-screen, (struct pipe_resource *)pool-bo); } +//In theory, all of the actual items were already freed in compute_memory_free... Just need to delete the list heads +free(pool-item_list); +free(pool-unallocated_list); +//And then the pool itself free(pool); } -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/4] aux/pipe_loader: Don't leak dlerror string on dlopen failure
dlopen allocates a string on dlopen failure which is retrieved via dlerror. In
order to free that string, you need to retrieve and then free it.
In order to keep things legit the windows/other util_dl_error paths allocate
and then copy their error message into a buffer as well.
Signed-off-by: Aaron Watry awa...@gmail.com
---
src/gallium/auxiliary/pipe-loader/pipe_loader.c | 5 +
src/gallium/auxiliary/util/u_dl.c | 13 +++--
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader.c
b/src/gallium/auxiliary/pipe-loader/pipe_loader.c
index 8e79f85..bf3acca 100644
--- a/src/gallium/auxiliary/pipe-loader/pipe_loader.c
+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader.c
@@ -25,6 +25,8 @@
*
**/
+#include dlfcn.h
+
#include pipe_loader_priv.h
#include util/u_inlines.h
@@ -101,6 +103,9 @@ pipe_loader_find_module(struct pipe_loader_device *dev,
if (lib) {
return lib;
}
+
+ //Retrieve the dlerror() str so that it can be freed properly
+ FREE(util_dl_error());
}
}
diff --git a/src/gallium/auxiliary/util/u_dl.c
b/src/gallium/auxiliary/util/u_dl.c
index aca435d..7f9231f 100644
--- a/src/gallium/auxiliary/util/u_dl.c
+++ b/src/gallium/auxiliary/util/u_dl.c
@@ -39,6 +39,7 @@
#include u_dl.h
#include u_pointer.h
+#include u_memory.h
struct util_dl_library *
@@ -87,8 +88,16 @@ util_dl_error(void)
#if defined(PIPE_OS_UNIX)
return dlerror();
#elif defined(PIPE_OS_WINDOWS)
- return unknown error;
+ char *error = CALLOC(14, sizeof(char));
+ if (error == NULL) {
+ return NULL;
+ }
+ return strcpy(error, unknown error);
#else
- return unknown error;
+ char *error = CALLOC(14, sizeof(char));
+ if (error == NULL) {
+ return NULL;
+ }
+ return strcpy(error, unknown error);
#endif
}
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] r600g/compute: Don't leak cbufs in compute state
Walk the array of cbufs backwards and free all of them.
Signed-off-by: Aaron Watry awa...@gmail.com
---
src/gallium/drivers/r600/evergreen_compute.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/src/gallium/drivers/r600/evergreen_compute.c
index 38b78c7..dcb7183 100644
--- a/src/gallium/drivers/r600/evergreen_compute.c
+++ b/src/gallium/drivers/r600/evergreen_compute.c
@@ -240,6 +240,15 @@ void evergreen_delete_compute_state(struct pipe_context
*ctx, void* state)
FREE(shader-kernels);
+if (shader-ctx){
+struct pipe_framebuffer_state *fb_state =
shader-ctx-framebuffer.state;
+for (int i = fb_state-nr_cbufs - 1; fb_state-nr_cbufs 0 ; i--){
+shader-ctx-b.b.surface_destroy(ctx, fb_state-cbufs[i]);
+fb_state-cbufs[i] = NULL;
+fb_state-nr_cbufs--;
+}
+}
+
#ifdef HAVE_OPENCL
if (shader-llvm_ctx){
LLVMContextDispose(shader-llvm_ctx);
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] aux/pipe_loader: Don't leak dlerror string on dlopen failure
On Thu, Aug 21, 2014 at 12:06 PM, Aaron Watry awa...@gmail.com wrote:
dlopen allocates a string on dlopen failure which is retrieved via dlerror. In
order to free that string, you need to retrieve and then free it.
In order to keep things legit the windows/other util_dl_error paths allocate
and then copy their error message into a buffer as well.
Signed-off-by: Aaron Watry awa...@gmail.com
---
src/gallium/auxiliary/pipe-loader/pipe_loader.c | 5 +
src/gallium/auxiliary/util/u_dl.c | 13 +++--
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader.c
b/src/gallium/auxiliary/pipe-loader/pipe_loader.c
index 8e79f85..bf3acca 100644
--- a/src/gallium/auxiliary/pipe-loader/pipe_loader.c
+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader.c
@@ -25,6 +25,8 @@
*
**/
+#include dlfcn.h
+
#include pipe_loader_priv.h
#include util/u_inlines.h
@@ -101,6 +103,9 @@ pipe_loader_find_module(struct pipe_loader_device *dev,
if (lib) {
return lib;
}
+
+ //Retrieve the dlerror() str so that it can be freed properly
+ FREE(util_dl_error());
}
}
diff --git a/src/gallium/auxiliary/util/u_dl.c
b/src/gallium/auxiliary/util/u_dl.c
index aca435d..7f9231f 100644
--- a/src/gallium/auxiliary/util/u_dl.c
+++ b/src/gallium/auxiliary/util/u_dl.c
@@ -39,6 +39,7 @@
#include u_dl.h
#include u_pointer.h
+#include u_memory.h
struct util_dl_library *
@@ -87,8 +88,16 @@ util_dl_error(void)
#if defined(PIPE_OS_UNIX)
return dlerror();
#elif defined(PIPE_OS_WINDOWS)
- return unknown error;
+ char *error = CALLOC(14, sizeof(char));
+ if (error == NULL) {
+ return NULL;
+ }
+ return strcpy(error, unknown error);
#else
- return unknown error;
+ char *error = CALLOC(14, sizeof(char));
+ if (error == NULL) {
+ return NULL;
+ }
+ return strcpy(error, unknown error);
return strdup(unknown error) seems like it'd be sufficient, no?
#endif
}
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] aux/pipe_loader: Don't leak dlerror string on dlopen failure
On Thu, Aug 21, 2014 at 11:09 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Thu, Aug 21, 2014 at 12:06 PM, Aaron Watry awa...@gmail.com wrote:
dlopen allocates a string on dlopen failure which is retrieved via dlerror.
In
order to free that string, you need to retrieve and then free it.
In order to keep things legit the windows/other util_dl_error paths allocate
and then copy their error message into a buffer as well.
Signed-off-by: Aaron Watry awa...@gmail.com
---
src/gallium/auxiliary/pipe-loader/pipe_loader.c | 5 +
src/gallium/auxiliary/util/u_dl.c | 13 +++--
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader.c
b/src/gallium/auxiliary/pipe-loader/pipe_loader.c
index 8e79f85..bf3acca 100644
--- a/src/gallium/auxiliary/pipe-loader/pipe_loader.c
+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader.c
@@ -25,6 +25,8 @@
*
**/
+#include dlfcn.h
+
#include pipe_loader_priv.h
#include util/u_inlines.h
@@ -101,6 +103,9 @@ pipe_loader_find_module(struct pipe_loader_device *dev,
if (lib) {
return lib;
}
+
+ //Retrieve the dlerror() str so that it can be freed properly
+ FREE(util_dl_error());
}
}
diff --git a/src/gallium/auxiliary/util/u_dl.c
b/src/gallium/auxiliary/util/u_dl.c
index aca435d..7f9231f 100644
--- a/src/gallium/auxiliary/util/u_dl.c
+++ b/src/gallium/auxiliary/util/u_dl.c
@@ -39,6 +39,7 @@
#include u_dl.h
#include u_pointer.h
+#include u_memory.h
struct util_dl_library *
@@ -87,8 +88,16 @@ util_dl_error(void)
#if defined(PIPE_OS_UNIX)
return dlerror();
#elif defined(PIPE_OS_WINDOWS)
- return unknown error;
+ char *error = CALLOC(14, sizeof(char));
+ if (error == NULL) {
+ return NULL;
+ }
+ return strcpy(error, unknown error);
#else
- return unknown error;
+ char *error = CALLOC(14, sizeof(char));
+ if (error == NULL) {
+ return NULL;
+ }
+ return strcpy(error, unknown error);
return strdup(unknown error) seems like it'd be sufficient, no?
Yeah, that'd be better. I'll send v2 shortly.
--Aaron
#endif
}
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] r600/compute: Don't leak compute pool item_list/unallocated_list
On Thu, Aug 21, 2014 at 12:06 PM, Aaron Watry awa...@gmail.com wrote: Signed-off-by: Aaron Watry awa...@gmail.com --- src/gallium/drivers/r600/compute_memory_pool.c | 4 1 file changed, 4 insertions(+) diff --git a/src/gallium/drivers/r600/compute_memory_pool.c b/src/gallium/drivers/r600/compute_memory_pool.c index 9324b84..55ff7d5 100644 --- a/src/gallium/drivers/r600/compute_memory_pool.c +++ b/src/gallium/drivers/r600/compute_memory_pool.c @@ -95,6 +95,10 @@ void compute_memory_pool_delete(struct compute_memory_pool* pool) pool-screen-b.b.resource_destroy((struct pipe_screen *) pool-screen, (struct pipe_resource *)pool-bo); } +//In theory, all of the actual items were already freed in compute_memory_free... Just need to delete the list heads +free(pool-item_list); +free(pool-unallocated_list); +//And then the pool itself Just some trivia -- you appear to have had a bit of an indentation fail on all the radeon patches in this series. Also I believe the style is not to use C99 (C++-style) comments in .c files: src/gallium/drivers/r600 $ git grep '//' | wc -l 397 src/gallium/drivers/r600 $ git grep '/\*' | wc -l 1587 (and the // are over-represented since each line gets one) free(pool); } -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] aux/pipe_loader: Don't leak dlerror string on dlopen failure
dlopen allocates a string on dlopen failure which is retrieved via dlerror. In
order to free that string, you need to retrieve and then free it.
In order to keep things legit the windows/other util_dl_error paths allocate
and then copy their error message into a buffer as well.
Signed-off-by: Aaron Watry awa...@gmail.com
CC: Ilia Mirkin imir...@alum.mit.edu
v2: Use strdup instead of calloc/strcpy
---
src/gallium/auxiliary/pipe-loader/pipe_loader.c | 5 +
src/gallium/auxiliary/util/u_dl.c | 4 ++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader.c
b/src/gallium/auxiliary/pipe-loader/pipe_loader.c
index 8e79f85..bf3acca 100644
--- a/src/gallium/auxiliary/pipe-loader/pipe_loader.c
+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader.c
@@ -25,6 +25,8 @@
*
**/
+#include dlfcn.h
+
#include pipe_loader_priv.h
#include util/u_inlines.h
@@ -101,6 +103,9 @@ pipe_loader_find_module(struct pipe_loader_device *dev,
if (lib) {
return lib;
}
+
+ //Retrieve the dlerror() str so that it can be freed properly
+ FREE(util_dl_error());
}
}
diff --git a/src/gallium/auxiliary/util/u_dl.c
b/src/gallium/auxiliary/util/u_dl.c
index aca435d..00c4d7c 100644
--- a/src/gallium/auxiliary/util/u_dl.c
+++ b/src/gallium/auxiliary/util/u_dl.c
@@ -87,8 +87,8 @@ util_dl_error(void)
#if defined(PIPE_OS_UNIX)
return dlerror();
#elif defined(PIPE_OS_WINDOWS)
- return unknown error;
+ return strdup(unknown error);
#else
- return unknown error;
+ return strdup(unknown error);
#endif
}
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] r600/compute: Don't leak compute pool item_list/unallocated_list
Yeah, I see that now. I changed my editor settings halfway through this series. I thought I had cleaned up the indentation outside of my IDE, but I guess I missed some spots. With regards to comment-style... I'll change it, but for the record, I really dislike using C-style comments for single-line comments. --Aaron On Thu, Aug 21, 2014 at 11:22 AM, Ilia Mirkin imir...@alum.mit.edu wrote: On Thu, Aug 21, 2014 at 12:06 PM, Aaron Watry awa...@gmail.com wrote: Signed-off-by: Aaron Watry awa...@gmail.com --- src/gallium/drivers/r600/compute_memory_pool.c | 4 1 file changed, 4 insertions(+) diff --git a/src/gallium/drivers/r600/compute_memory_pool.c b/src/gallium/drivers/r600/compute_memory_pool.c index 9324b84..55ff7d5 100644 --- a/src/gallium/drivers/r600/compute_memory_pool.c +++ b/src/gallium/drivers/r600/compute_memory_pool.c @@ -95,6 +95,10 @@ void compute_memory_pool_delete(struct compute_memory_pool* pool) pool-screen-b.b.resource_destroy((struct pipe_screen *) pool-screen, (struct pipe_resource *)pool-bo); } +//In theory, all of the actual items were already freed in compute_memory_free... Just need to delete the list heads +free(pool-item_list); +free(pool-unallocated_list); +//And then the pool itself Just some trivia -- you appear to have had a bit of an indentation fail on all the radeon patches in this series. Also I believe the style is not to use C99 (C++-style) comments in .c files: src/gallium/drivers/r600 $ git grep '//' | wc -l 397 src/gallium/drivers/r600 $ git grep '/\*' | wc -l 1587 (and the // are over-represented since each line gets one) free(pool); } -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC] gallium: add support for rectangle primitives
From: Marek Olšák marek.ol...@amd.com
This is already supported by r600g and radeonsi.
Alex suggested this could be useful for video acceleration state trackers.
---
src/gallium/auxiliary/tgsi/tgsi_strings.c | 3 ++-
src/gallium/auxiliary/util/u_prim.h | 1 +
src/gallium/docs/source/screen.rst| 6 ++
src/gallium/drivers/r600/r600_pipe.c | 1 +
src/gallium/drivers/radeon/r600_pipe_common.h | 2 +-
src/gallium/drivers/radeonsi/si_pipe.c| 1 +
src/gallium/include/pipe/p_defines.h | 4 +++-
7 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_strings.c
b/src/gallium/auxiliary/tgsi/tgsi_strings.c
index 3c108a8..ddc23c1 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_strings.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_strings.c
@@ -164,7 +164,8 @@ const char *tgsi_primitive_names[PIPE_PRIM_MAX] =
LINES_ADJACENCY,
LINE_STRIP_ADJACENCY,
TRIANGLES_ADJACENCY,
- TRIANGLE_STRIP_ADJACENCY
+ TRIANGLE_STRIP_ADJACENCY,
+ RECTANGLES
};
const char *tgsi_fs_coord_origin_names[2] =
diff --git a/src/gallium/auxiliary/util/u_prim.h
b/src/gallium/auxiliary/util/u_prim.h
index cf1a18f..d631dc1 100644
--- a/src/gallium/auxiliary/util/u_prim.h
+++ b/src/gallium/auxiliary/util/u_prim.h
@@ -131,6 +131,7 @@ u_prim_vertex_count(unsigned prim)
{ 4, 1 }, /* PIPE_PRIM_LINE_STRIP_ADJACENCY */
{ 6, 6 }, /* PIPE_PRIM_TRIANGLES_ADJACENCY */
{ 6, 2 }, /* PIPE_PRIM_TRIANGLE_STRIP_ADJACENCY */
+ { 3, 3 } /* PIPE_PRIM_RECTANGLES */
};
return (likely(prim PIPE_PRIM_MAX)) ? prim_table[prim] : NULL;
diff --git a/src/gallium/docs/source/screen.rst
b/src/gallium/docs/source/screen.rst
index eee254e..f162ec0 100644
--- a/src/gallium/docs/source/screen.rst
+++ b/src/gallium/docs/source/screen.rst
@@ -26,6 +26,12 @@ The integer capabilities:
normalized coordinates, and mipmaps.
* ``PIPE_CAP_TWO_SIDED_STENCIL``: Whether the stencil test can also affect
back-facing
polygons.
+* ``PIPE_CAP_PRIM_TYPE_RECTANGLES``: Whether rectangle primitives are
supported.
+ Rectangles are like quads, but they are only specified by the first 3
vertices.
+ The 4th vertex is computed from the first three by hardware. Rectangles must
+ be parallel with screen borders, which means they can only be rotated with
+ 90-degree increments. Rectangles bypass clipping and therefore can be
specified
+ in screen coordinates.
* ``PIPE_CAP_MAX_DUAL_SOURCE_RENDER_TARGETS``: How many dual-source blend RTs
are support.
:ref:`Blend` for more information.
* ``PIPE_CAP_ANISOTROPIC_FILTER``: Whether textures can be filtered
anisotropically.
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index 3d07864..7294c8c 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
+++ b/src/gallium/drivers/r600/r600_pipe.c
@@ -262,6 +262,7 @@ static int r600_get_param(struct pipe_screen* pscreen, enum
pipe_cap param)
case PIPE_CAP_BUFFER_MAP_PERSISTENT_COHERENT:
case PIPE_CAP_TGSI_VS_WINDOW_SPACE_POSITION:
case PIPE_CAP_TGSI_VS_LAYER_VIEWPORT:
+ case PIPE_CAP_PRIM_TYPE_RECTANGLES:
return 1;
case PIPE_CAP_COMPUTE:
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h
b/src/gallium/drivers/radeon/r600_pipe_common.h
index ed16e1a..903395d 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.h
+++ b/src/gallium/drivers/radeon/r600_pipe_common.h
@@ -76,7 +76,7 @@
#define R600_CONTEXT_VGT_STREAMOUT_SYNC(1 20)
/* special primitive types */
-#define R600_PRIM_RECTANGLE_LIST PIPE_PRIM_MAX
+#define R600_PRIM_RECTANGLE_LIST PIPE_PRIM_RECTANGLES
/* Debug flags. */
/* logging */
diff --git a/src/gallium/drivers/radeonsi/si_pipe.c
b/src/gallium/drivers/radeonsi/si_pipe.c
index ae1d043..9431ea4 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -216,6 +216,7 @@ static int si_get_param(struct pipe_screen* pscreen, enum
pipe_cap param)
case PIPE_CAP_CUBE_MAP_ARRAY:
case PIPE_CAP_SAMPLE_SHADING:
case PIPE_CAP_DRAW_INDIRECT:
+ case PIPE_CAP_PRIM_TYPE_RECTANGLES:
return 1;
case PIPE_CAP_TEXTURE_MULTISAMPLE:
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index 04e4798..d92261c 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -419,7 +419,8 @@ enum pipe_flush_flags {
#define PIPE_PRIM_LINE_STRIP_ADJACENCY11
#define PIPE_PRIM_TRIANGLES_ADJACENCY 12
#define PIPE_PRIM_TRIANGLE_STRIP_ADJACENCY 13
-#define PIPE_PRIM_MAX 14
+#define PIPE_PRIM_RECTANGLES 14
+#define PIPE_PRIM_MAX 15
/**
@@ -479,6 +480,7 @@ enum pipe_flush_flags {
enum pipe_cap {
PIPE_CAP_NPOT_TEXTURES = 1,
PIPE_CAP_TWO_SIDED_STENCIL = 2,
+ PIPE_CAP_PRIM_TYPE_RECTANGLES = 3,
Re: [Mesa-dev] [RFC] gallium: add support for rectangle primitives
Am 21.08.2014 um 18:44 schrieb Marek Olšák:
From: Marek Olšák marek.ol...@amd.com
This is already supported by r600g and radeonsi.
Alex suggested this could be useful for video acceleration state trackers.
I'm a bit skeptical about their usefulness for video applications, but
when you draw a lot of quads it might actually worth it.
Anyway the patch itself looks good and is Reviewed-by: Christian König
christian.koe...@amd.com
---
src/gallium/auxiliary/tgsi/tgsi_strings.c | 3 ++-
src/gallium/auxiliary/util/u_prim.h | 1 +
src/gallium/docs/source/screen.rst| 6 ++
src/gallium/drivers/r600/r600_pipe.c | 1 +
src/gallium/drivers/radeon/r600_pipe_common.h | 2 +-
src/gallium/drivers/radeonsi/si_pipe.c| 1 +
src/gallium/include/pipe/p_defines.h | 4 +++-
7 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_strings.c
b/src/gallium/auxiliary/tgsi/tgsi_strings.c
index 3c108a8..ddc23c1 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_strings.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_strings.c
@@ -164,7 +164,8 @@ const char *tgsi_primitive_names[PIPE_PRIM_MAX] =
LINES_ADJACENCY,
LINE_STRIP_ADJACENCY,
TRIANGLES_ADJACENCY,
- TRIANGLE_STRIP_ADJACENCY
+ TRIANGLE_STRIP_ADJACENCY,
+ RECTANGLES
};
const char *tgsi_fs_coord_origin_names[2] =
diff --git a/src/gallium/auxiliary/util/u_prim.h
b/src/gallium/auxiliary/util/u_prim.h
index cf1a18f..d631dc1 100644
--- a/src/gallium/auxiliary/util/u_prim.h
+++ b/src/gallium/auxiliary/util/u_prim.h
@@ -131,6 +131,7 @@ u_prim_vertex_count(unsigned prim)
{ 4, 1 }, /* PIPE_PRIM_LINE_STRIP_ADJACENCY */
{ 6, 6 }, /* PIPE_PRIM_TRIANGLES_ADJACENCY */
{ 6, 2 }, /* PIPE_PRIM_TRIANGLE_STRIP_ADJACENCY */
+ { 3, 3 } /* PIPE_PRIM_RECTANGLES */
};
return (likely(prim PIPE_PRIM_MAX)) ? prim_table[prim] : NULL;
diff --git a/src/gallium/docs/source/screen.rst
b/src/gallium/docs/source/screen.rst
index eee254e..f162ec0 100644
--- a/src/gallium/docs/source/screen.rst
+++ b/src/gallium/docs/source/screen.rst
@@ -26,6 +26,12 @@ The integer capabilities:
normalized coordinates, and mipmaps.
* ``PIPE_CAP_TWO_SIDED_STENCIL``: Whether the stencil test can also affect
back-facing
polygons.
+* ``PIPE_CAP_PRIM_TYPE_RECTANGLES``: Whether rectangle primitives are
supported.
+ Rectangles are like quads, but they are only specified by the first 3
vertices.
+ The 4th vertex is computed from the first three by hardware. Rectangles must
+ be parallel with screen borders, which means they can only be rotated with
+ 90-degree increments. Rectangles bypass clipping and therefore can be
specified
+ in screen coordinates.
* ``PIPE_CAP_MAX_DUAL_SOURCE_RENDER_TARGETS``: How many dual-source blend RTs
are support.
:ref:`Blend` for more information.
* ``PIPE_CAP_ANISOTROPIC_FILTER``: Whether textures can be filtered
anisotropically.
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index 3d07864..7294c8c 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
+++ b/src/gallium/drivers/r600/r600_pipe.c
@@ -262,6 +262,7 @@ static int r600_get_param(struct pipe_screen* pscreen, enum
pipe_cap param)
case PIPE_CAP_BUFFER_MAP_PERSISTENT_COHERENT:
case PIPE_CAP_TGSI_VS_WINDOW_SPACE_POSITION:
case PIPE_CAP_TGSI_VS_LAYER_VIEWPORT:
+ case PIPE_CAP_PRIM_TYPE_RECTANGLES:
return 1;
case PIPE_CAP_COMPUTE:
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h
b/src/gallium/drivers/radeon/r600_pipe_common.h
index ed16e1a..903395d 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.h
+++ b/src/gallium/drivers/radeon/r600_pipe_common.h
@@ -76,7 +76,7 @@
#define R600_CONTEXT_VGT_STREAMOUT_SYNC (1 20)
/* special primitive types */
-#define R600_PRIM_RECTANGLE_LIST PIPE_PRIM_MAX
+#define R600_PRIM_RECTANGLE_LIST PIPE_PRIM_RECTANGLES
/* Debug flags. */
/* logging */
diff --git a/src/gallium/drivers/radeonsi/si_pipe.c
b/src/gallium/drivers/radeonsi/si_pipe.c
index ae1d043..9431ea4 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -216,6 +216,7 @@ static int si_get_param(struct pipe_screen* pscreen, enum
pipe_cap param)
case PIPE_CAP_CUBE_MAP_ARRAY:
case PIPE_CAP_SAMPLE_SHADING:
case PIPE_CAP_DRAW_INDIRECT:
+ case PIPE_CAP_PRIM_TYPE_RECTANGLES:
return 1;
case PIPE_CAP_TEXTURE_MULTISAMPLE:
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index 04e4798..d92261c 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -419,7 +419,8 @@ enum pipe_flush_flags {
#define PIPE_PRIM_LINE_STRIP_ADJACENCY11
#define PIPE_PRIM_TRIANGLES_ADJACENCY 12
#define PIPE_PRIM_TRIANGLE_STRIP_ADJACENCY 13
-#define
Re: [Mesa-dev] [RFC] gallium: add support for rectangle primitives
Am 21.08.2014 18:44, schrieb Marek Olšák:
From: Marek Olšák marek.ol...@amd.com
This is already supported by r600g and radeonsi.
Alex suggested this could be useful for video acceleration state trackers.
---
src/gallium/auxiliary/tgsi/tgsi_strings.c | 3 ++-
src/gallium/auxiliary/util/u_prim.h | 1 +
src/gallium/docs/source/screen.rst| 6 ++
src/gallium/drivers/r600/r600_pipe.c | 1 +
src/gallium/drivers/radeon/r600_pipe_common.h | 2 +-
src/gallium/drivers/radeonsi/si_pipe.c| 1 +
src/gallium/include/pipe/p_defines.h | 4 +++-
7 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_strings.c
b/src/gallium/auxiliary/tgsi/tgsi_strings.c
index 3c108a8..ddc23c1 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_strings.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_strings.c
@@ -164,7 +164,8 @@ const char *tgsi_primitive_names[PIPE_PRIM_MAX] =
LINES_ADJACENCY,
LINE_STRIP_ADJACENCY,
TRIANGLES_ADJACENCY,
- TRIANGLE_STRIP_ADJACENCY
+ TRIANGLE_STRIP_ADJACENCY,
+ RECTANGLES
};
const char *tgsi_fs_coord_origin_names[2] =
diff --git a/src/gallium/auxiliary/util/u_prim.h
b/src/gallium/auxiliary/util/u_prim.h
index cf1a18f..d631dc1 100644
--- a/src/gallium/auxiliary/util/u_prim.h
+++ b/src/gallium/auxiliary/util/u_prim.h
@@ -131,6 +131,7 @@ u_prim_vertex_count(unsigned prim)
{ 4, 1 }, /* PIPE_PRIM_LINE_STRIP_ADJACENCY */
{ 6, 6 }, /* PIPE_PRIM_TRIANGLES_ADJACENCY */
{ 6, 2 }, /* PIPE_PRIM_TRIANGLE_STRIP_ADJACENCY */
+ { 3, 3 } /* PIPE_PRIM_RECTANGLES */
};
return (likely(prim PIPE_PRIM_MAX)) ? prim_table[prim] : NULL;
diff --git a/src/gallium/docs/source/screen.rst
b/src/gallium/docs/source/screen.rst
index eee254e..f162ec0 100644
--- a/src/gallium/docs/source/screen.rst
+++ b/src/gallium/docs/source/screen.rst
@@ -26,6 +26,12 @@ The integer capabilities:
normalized coordinates, and mipmaps.
* ``PIPE_CAP_TWO_SIDED_STENCIL``: Whether the stencil test can also affect
back-facing
polygons.
+* ``PIPE_CAP_PRIM_TYPE_RECTANGLES``: Whether rectangle primitives are
supported.
+ Rectangles are like quads, but they are only specified by the first 3
vertices.
+ The 4th vertex is computed from the first three by hardware. Rectangles
must
+ be parallel with screen borders, which means they can only be rotated with
+ 90-degree increments. Rectangles bypass clipping and therefore can be
specified
+ in screen coordinates.
Do they also need to be planar (same z for each vertex)?
Also, the implicit bypass clip / screen coordinate specification makes
them quite an outlier among all the primitives. Hmm...
* ``PIPE_CAP_MAX_DUAL_SOURCE_RENDER_TARGETS``: How many dual-source blend
RTs are support.
:ref:`Blend` for more information.
* ``PIPE_CAP_ANISOTROPIC_FILTER``: Whether textures can be filtered
anisotropically.
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index 3d07864..7294c8c 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
+++ b/src/gallium/drivers/r600/r600_pipe.c
@@ -262,6 +262,7 @@ static int r600_get_param(struct pipe_screen* pscreen,
enum pipe_cap param)
case PIPE_CAP_BUFFER_MAP_PERSISTENT_COHERENT:
case PIPE_CAP_TGSI_VS_WINDOW_SPACE_POSITION:
case PIPE_CAP_TGSI_VS_LAYER_VIEWPORT:
+ case PIPE_CAP_PRIM_TYPE_RECTANGLES:
return 1;
case PIPE_CAP_COMPUTE:
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h
b/src/gallium/drivers/radeon/r600_pipe_common.h
index ed16e1a..903395d 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.h
+++ b/src/gallium/drivers/radeon/r600_pipe_common.h
@@ -76,7 +76,7 @@
#define R600_CONTEXT_VGT_STREAMOUT_SYNC (1 20)
/* special primitive types */
-#define R600_PRIM_RECTANGLE_LIST PIPE_PRIM_MAX
+#define R600_PRIM_RECTANGLE_LIST PIPE_PRIM_RECTANGLES
/* Debug flags. */
/* logging */
diff --git a/src/gallium/drivers/radeonsi/si_pipe.c
b/src/gallium/drivers/radeonsi/si_pipe.c
index ae1d043..9431ea4 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -216,6 +216,7 @@ static int si_get_param(struct pipe_screen* pscreen, enum
pipe_cap param)
case PIPE_CAP_CUBE_MAP_ARRAY:
case PIPE_CAP_SAMPLE_SHADING:
case PIPE_CAP_DRAW_INDIRECT:
+ case PIPE_CAP_PRIM_TYPE_RECTANGLES:
return 1;
case PIPE_CAP_TEXTURE_MULTISAMPLE:
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index 04e4798..d92261c 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -419,7 +419,8 @@ enum pipe_flush_flags {
#define PIPE_PRIM_LINE_STRIP_ADJACENCY11
#define PIPE_PRIM_TRIANGLES_ADJACENCY 12
#define PIPE_PRIM_TRIANGLE_STRIP_ADJACENCY 13
-#define
Re: [Mesa-dev] [RFC] gallium: add support for rectangle primitives
On 21/08/14 17:59, Roland Scheidegger wrote:
Am 21.08.2014 18:44, schrieb Marek Olšák:
From: Marek Olšák marek.ol...@amd.com
This is already supported by r600g and radeonsi.
Alex suggested this could be useful for video acceleration state trackers.
---
src/gallium/auxiliary/tgsi/tgsi_strings.c | 3 ++-
src/gallium/auxiliary/util/u_prim.h | 1 +
src/gallium/docs/source/screen.rst| 6 ++
src/gallium/drivers/r600/r600_pipe.c | 1 +
src/gallium/drivers/radeon/r600_pipe_common.h | 2 +-
src/gallium/drivers/radeonsi/si_pipe.c| 1 +
src/gallium/include/pipe/p_defines.h | 4 +++-
7 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_strings.c
b/src/gallium/auxiliary/tgsi/tgsi_strings.c
index 3c108a8..ddc23c1 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_strings.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_strings.c
@@ -164,7 +164,8 @@ const char *tgsi_primitive_names[PIPE_PRIM_MAX] =
LINES_ADJACENCY,
LINE_STRIP_ADJACENCY,
TRIANGLES_ADJACENCY,
- TRIANGLE_STRIP_ADJACENCY
+ TRIANGLE_STRIP_ADJACENCY,
+ RECTANGLES
};
const char *tgsi_fs_coord_origin_names[2] =
diff --git a/src/gallium/auxiliary/util/u_prim.h
b/src/gallium/auxiliary/util/u_prim.h
index cf1a18f..d631dc1 100644
--- a/src/gallium/auxiliary/util/u_prim.h
+++ b/src/gallium/auxiliary/util/u_prim.h
@@ -131,6 +131,7 @@ u_prim_vertex_count(unsigned prim)
{ 4, 1 }, /* PIPE_PRIM_LINE_STRIP_ADJACENCY */
{ 6, 6 }, /* PIPE_PRIM_TRIANGLES_ADJACENCY */
{ 6, 2 }, /* PIPE_PRIM_TRIANGLE_STRIP_ADJACENCY */
+ { 3, 3 } /* PIPE_PRIM_RECTANGLES */
};
return (likely(prim PIPE_PRIM_MAX)) ? prim_table[prim] : NULL;
diff --git a/src/gallium/docs/source/screen.rst
b/src/gallium/docs/source/screen.rst
index eee254e..f162ec0 100644
--- a/src/gallium/docs/source/screen.rst
+++ b/src/gallium/docs/source/screen.rst
@@ -26,6 +26,12 @@ The integer capabilities:
normalized coordinates, and mipmaps.
* ``PIPE_CAP_TWO_SIDED_STENCIL``: Whether the stencil test can also affect
back-facing
polygons.
+* ``PIPE_CAP_PRIM_TYPE_RECTANGLES``: Whether rectangle primitives are
supported.
+ Rectangles are like quads, but they are only specified by the first 3
vertices.
+ The 4th vertex is computed from the first three by hardware. Rectangles must
+ be parallel with screen borders, which means they can only be rotated with
+ 90-degree increments. Rectangles bypass clipping and therefore can be
specified
+ in screen coordinates.
Do they also need to be planar (same z for each vertex)?
Also, the implicit bypass clip / screen coordinate specification makes
them quite an outlier among all the primitives. Hmm...
Yes, these restrictions would impose a lot of special casing if e.g.,
softpipe/llvmpipe wanted to support these. And rects are particularly
interesting for software rasterizers, as they can be rasterized much
more efficiently.
Does r600g/radeonsi's hardware support for rect impose these
restrictions? Or could rect be made work more like other primitives?
Jose
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] gallium: add support for rectangle primitives
On Thu, Aug 21, 2014 at 7:14 PM, Jose Fonseca jfons...@vmware.com wrote:
On 21/08/14 17:59, Roland Scheidegger wrote:
Am 21.08.2014 18:44, schrieb Marek Olšák:
From: Marek Olšák marek.ol...@amd.com
This is already supported by r600g and radeonsi.
Alex suggested this could be useful for video acceleration state
trackers.
---
src/gallium/auxiliary/tgsi/tgsi_strings.c | 3 ++-
src/gallium/auxiliary/util/u_prim.h | 1 +
src/gallium/docs/source/screen.rst| 6 ++
src/gallium/drivers/r600/r600_pipe.c | 1 +
src/gallium/drivers/radeon/r600_pipe_common.h | 2 +-
src/gallium/drivers/radeonsi/si_pipe.c| 1 +
src/gallium/include/pipe/p_defines.h | 4 +++-
7 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_strings.c
b/src/gallium/auxiliary/tgsi/tgsi_strings.c
index 3c108a8..ddc23c1 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_strings.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_strings.c
@@ -164,7 +164,8 @@ const char *tgsi_primitive_names[PIPE_PRIM_MAX] =
LINES_ADJACENCY,
LINE_STRIP_ADJACENCY,
TRIANGLES_ADJACENCY,
- TRIANGLE_STRIP_ADJACENCY
+ TRIANGLE_STRIP_ADJACENCY,
+ RECTANGLES
};
const char *tgsi_fs_coord_origin_names[2] =
diff --git a/src/gallium/auxiliary/util/u_prim.h
b/src/gallium/auxiliary/util/u_prim.h
index cf1a18f..d631dc1 100644
--- a/src/gallium/auxiliary/util/u_prim.h
+++ b/src/gallium/auxiliary/util/u_prim.h
@@ -131,6 +131,7 @@ u_prim_vertex_count(unsigned prim)
{ 4, 1 }, /* PIPE_PRIM_LINE_STRIP_ADJACENCY */
{ 6, 6 }, /* PIPE_PRIM_TRIANGLES_ADJACENCY */
{ 6, 2 }, /* PIPE_PRIM_TRIANGLE_STRIP_ADJACENCY */
+ { 3, 3 } /* PIPE_PRIM_RECTANGLES */
};
return (likely(prim PIPE_PRIM_MAX)) ? prim_table[prim] : NULL;
diff --git a/src/gallium/docs/source/screen.rst
b/src/gallium/docs/source/screen.rst
index eee254e..f162ec0 100644
--- a/src/gallium/docs/source/screen.rst
+++ b/src/gallium/docs/source/screen.rst
@@ -26,6 +26,12 @@ The integer capabilities:
normalized coordinates, and mipmaps.
* ``PIPE_CAP_TWO_SIDED_STENCIL``: Whether the stencil test can also
affect back-facing
polygons.
+* ``PIPE_CAP_PRIM_TYPE_RECTANGLES``: Whether rectangle primitives are
supported.
+ Rectangles are like quads, but they are only specified by the first 3
vertices.
+ The 4th vertex is computed from the first three by hardware.
Rectangles must
+ be parallel with screen borders, which means they can only be rotated
with
+ 90-degree increments. Rectangles bypass clipping and therefore can be
specified
+ in screen coordinates.
Do they also need to be planar (same z for each vertex)?
Also, the implicit bypass clip / screen coordinate specification makes
them quite an outlier among all the primitives. Hmm...
Yes, these restrictions would impose a lot of special casing if e.g.,
softpipe/llvmpipe wanted to support these. And rects are particularly
interesting for software rasterizers, as they can be rasterized much more
efficiently.
Does r600g/radeonsi's hardware support for rect impose these restrictions?
Or could rect be made work more like other primitives?
The restrictions I described in screen.rst are based on r600/radeonsi
restrictions.
I'm not sure if rectangles need to be planar, but let's assume they do.
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 2/4] gallium: add a texture target to sampler view and a CAP to use it
Am 21.08.2014 04:42, schrieb Ilia Mirkin: This allows a sampler view to have a different texture target than the underlying resource. This will be used to implement the type casting between 2d arrays and cube maps as specified in ARB_texture_view. Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- src/gallium/auxiliary/util/u_sampler.c | 1 + src/gallium/docs/source/screen.rst | 3 +++ src/gallium/drivers/freedreno/freedreno_screen.c | 1 + src/gallium/drivers/i915/i915_screen.c | 1 + src/gallium/drivers/ilo/ilo_screen.c | 1 + src/gallium/drivers/llvmpipe/lp_screen.c | 1 + src/gallium/drivers/nouveau/nv30/nv30_screen.c | 1 + src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 + src/gallium/drivers/nouveau/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/si_pipe.c | 1 + src/gallium/drivers/softpipe/sp_screen.c | 1 + src/gallium/drivers/svga/svga_screen.c | 1 + src/gallium/drivers/vc4/vc4_screen.c | 1 + src/gallium/include/pipe/p_defines.h | 1 + src/gallium/include/pipe/p_state.h | 1 + 17 files changed, 19 insertions(+) diff --git a/src/gallium/auxiliary/util/u_sampler.c b/src/gallium/auxiliary/util/u_sampler.c index 227641b..86799fd 100644 --- a/src/gallium/auxiliary/util/u_sampler.c +++ b/src/gallium/auxiliary/util/u_sampler.c @@ -45,6 +45,7 @@ default_template(struct pipe_sampler_view *view, /* XXX: Check if format is compatible with texture-format. */ + view-target = texture-target; view-format = format; view-u.tex.first_level = 0; view-u.tex.last_level = texture-last_level; diff --git a/src/gallium/docs/source/screen.rst b/src/gallium/docs/source/screen.rst index eee254e..8feeb56 100644 --- a/src/gallium/docs/source/screen.rst +++ b/src/gallium/docs/source/screen.rst @@ -225,6 +225,9 @@ The integer capabilities: memory and GART. * ``PIPE_CAP_CONDITIONAL_RENDER_INVERTED``: Whether the driver supports inverted condition for conditional rendering. +* ``PIPE_CAP_SAMPLER_VIEW_TARGET``: Whether the sampler view's target can be + different than the underlying resource's. This can happen when casting + between 2d array and cube map (array) textures. I'd like to see some more precise language, because even if the difference between array and non-array textures may seem trivial and not matter much usually, it can happen too. Just a minor nitpick, though. .. _pipe_capf: diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c b/src/gallium/drivers/freedreno/freedreno_screen.c index ab1a740..165ec8d 100644 --- a/src/gallium/drivers/freedreno/freedreno_screen.c +++ b/src/gallium/drivers/freedreno/freedreno_screen.c @@ -218,6 +218,7 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_DRAW_INDIRECT: case PIPE_CAP_TGSI_FS_FINE_DERIVATIVE: case PIPE_CAP_CONDITIONAL_RENDER_INVERTED: + case PIPE_CAP_SAMPLER_VIEW_TARGET: return 0; /* Stream output. */ diff --git a/src/gallium/drivers/i915/i915_screen.c b/src/gallium/drivers/i915/i915_screen.c index 40976b3..4b70abe 100644 --- a/src/gallium/drivers/i915/i915_screen.c +++ b/src/gallium/drivers/i915/i915_screen.c @@ -234,6 +234,7 @@ i915_get_param(struct pipe_screen *screen, enum pipe_cap cap) case PIPE_CAP_BUFFER_MAP_PERSISTENT_COHERENT: case PIPE_CAP_DRAW_INDIRECT: case PIPE_CAP_TGSI_FS_FINE_DERIVATIVE: + case PIPE_CAP_SAMPLER_VIEW_TARGET: return 0; case PIPE_CAP_MIN_MAP_BUFFER_ALIGNMENT: diff --git a/src/gallium/drivers/ilo/ilo_screen.c b/src/gallium/drivers/ilo/ilo_screen.c index 15658da..9200f55 100644 --- a/src/gallium/drivers/ilo/ilo_screen.c +++ b/src/gallium/drivers/ilo/ilo_screen.c @@ -436,6 +436,7 @@ ilo_get_param(struct pipe_screen *screen, enum pipe_cap param) case PIPE_CAP_DRAW_INDIRECT: case PIPE_CAP_TGSI_FS_FINE_DERIVATIVE: case PIPE_CAP_CONDITIONAL_RENDER_INVERTED: + case PIPE_CAP_SAMPLER_VIEW_TARGET: return 0; case PIPE_CAP_VENDOR_ID: diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c b/src/gallium/drivers/llvmpipe/lp_screen.c index 2a6e673..b10ddfb 100644 --- a/src/gallium/drivers/llvmpipe/lp_screen.c +++ b/src/gallium/drivers/llvmpipe/lp_screen.c @@ -250,6 +250,7 @@ llvmpipe_get_param(struct pipe_screen *screen, enum pipe_cap param) case PIPE_CAP_TEXTURE_GATHER_OFFSETS: case PIPE_CAP_TGSI_VS_WINDOW_SPACE_POSITION: case PIPE_CAP_TGSI_FS_FINE_DERIVATIVE: + case PIPE_CAP_SAMPLER_VIEW_TARGET: return 0; case PIPE_CAP_FAKE_SW_MSAA: return 1; diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c b/src/gallium/drivers/nouveau/nv30/nv30_screen.c index 80d6943..947140a 100644
Re: [Mesa-dev] [PATCH v2 2/4] gallium: add a texture target to sampler view and a CAP to use it
On Thu, Aug 21, 2014 at 1:35 PM, Roland Scheidegger srol...@vmware.com wrote: Am 21.08.2014 04:42, schrieb Ilia Mirkin: This allows a sampler view to have a different texture target than the underlying resource. This will be used to implement the type casting between 2d arrays and cube maps as specified in ARB_texture_view. Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- src/gallium/auxiliary/util/u_sampler.c | 1 + src/gallium/docs/source/screen.rst | 3 +++ src/gallium/drivers/freedreno/freedreno_screen.c | 1 + src/gallium/drivers/i915/i915_screen.c | 1 + src/gallium/drivers/ilo/ilo_screen.c | 1 + src/gallium/drivers/llvmpipe/lp_screen.c | 1 + src/gallium/drivers/nouveau/nv30/nv30_screen.c | 1 + src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 + src/gallium/drivers/nouveau/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/si_pipe.c | 1 + src/gallium/drivers/softpipe/sp_screen.c | 1 + src/gallium/drivers/svga/svga_screen.c | 1 + src/gallium/drivers/vc4/vc4_screen.c | 1 + src/gallium/include/pipe/p_defines.h | 1 + src/gallium/include/pipe/p_state.h | 1 + 17 files changed, 19 insertions(+) diff --git a/src/gallium/auxiliary/util/u_sampler.c b/src/gallium/auxiliary/util/u_sampler.c index 227641b..86799fd 100644 --- a/src/gallium/auxiliary/util/u_sampler.c +++ b/src/gallium/auxiliary/util/u_sampler.c @@ -45,6 +45,7 @@ default_template(struct pipe_sampler_view *view, /* XXX: Check if format is compatible with texture-format. */ + view-target = texture-target; view-format = format; view-u.tex.first_level = 0; view-u.tex.last_level = texture-last_level; diff --git a/src/gallium/docs/source/screen.rst b/src/gallium/docs/source/screen.rst index eee254e..8feeb56 100644 --- a/src/gallium/docs/source/screen.rst +++ b/src/gallium/docs/source/screen.rst @@ -225,6 +225,9 @@ The integer capabilities: memory and GART. * ``PIPE_CAP_CONDITIONAL_RENDER_INVERTED``: Whether the driver supports inverted condition for conditional rendering. +* ``PIPE_CAP_SAMPLER_VIEW_TARGET``: Whether the sampler view's target can be + different than the underlying resource's. This can happen when casting + between 2d array and cube map (array) textures. I'd like to see some more precise language, because even if the difference between array and non-array textures may seem trivial and not matter much usually, it can happen too. Just a minor nitpick, though. Happy to provide any language you deem appropriate. Perhaps only some differences need to be handled? I guess even nouveau wouldn't be particularly happy if you tried to cast a 3d texture to a cube map because of how levels work. .. _pipe_capf: diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c b/src/gallium/drivers/freedreno/freedreno_screen.c index ab1a740..165ec8d 100644 --- a/src/gallium/drivers/freedreno/freedreno_screen.c +++ b/src/gallium/drivers/freedreno/freedreno_screen.c @@ -218,6 +218,7 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_DRAW_INDIRECT: case PIPE_CAP_TGSI_FS_FINE_DERIVATIVE: case PIPE_CAP_CONDITIONAL_RENDER_INVERTED: + case PIPE_CAP_SAMPLER_VIEW_TARGET: return 0; /* Stream output. */ diff --git a/src/gallium/drivers/i915/i915_screen.c b/src/gallium/drivers/i915/i915_screen.c index 40976b3..4b70abe 100644 --- a/src/gallium/drivers/i915/i915_screen.c +++ b/src/gallium/drivers/i915/i915_screen.c @@ -234,6 +234,7 @@ i915_get_param(struct pipe_screen *screen, enum pipe_cap cap) case PIPE_CAP_BUFFER_MAP_PERSISTENT_COHERENT: case PIPE_CAP_DRAW_INDIRECT: case PIPE_CAP_TGSI_FS_FINE_DERIVATIVE: + case PIPE_CAP_SAMPLER_VIEW_TARGET: return 0; case PIPE_CAP_MIN_MAP_BUFFER_ALIGNMENT: diff --git a/src/gallium/drivers/ilo/ilo_screen.c b/src/gallium/drivers/ilo/ilo_screen.c index 15658da..9200f55 100644 --- a/src/gallium/drivers/ilo/ilo_screen.c +++ b/src/gallium/drivers/ilo/ilo_screen.c @@ -436,6 +436,7 @@ ilo_get_param(struct pipe_screen *screen, enum pipe_cap param) case PIPE_CAP_DRAW_INDIRECT: case PIPE_CAP_TGSI_FS_FINE_DERIVATIVE: case PIPE_CAP_CONDITIONAL_RENDER_INVERTED: + case PIPE_CAP_SAMPLER_VIEW_TARGET: return 0; case PIPE_CAP_VENDOR_ID: diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c b/src/gallium/drivers/llvmpipe/lp_screen.c index 2a6e673..b10ddfb 100644 --- a/src/gallium/drivers/llvmpipe/lp_screen.c +++ b/src/gallium/drivers/llvmpipe/lp_screen.c @@ -250,6 +250,7 @@ llvmpipe_get_param(struct pipe_screen *screen, enum pipe_cap param) case PIPE_CAP_TEXTURE_GATHER_OFFSETS: case
Re: [Mesa-dev] [PATCH v2 3/4] mesa/st: add ARB_texture_view support
Am 21.08.2014 04:42, schrieb Ilia Mirkin:
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
v1 - v2:
- make use of new PIPE_CAP to determine whether ARB_texture_view is available
- set the gl_texture_object's Target in the sampler view object
src/mesa/state_tracker/st_atom_texture.c | 30
src/mesa/state_tracker/st_cb_fbo.c | 10 ++
src/mesa/state_tracker/st_cb_texture.c | 62
+++-
src/mesa/state_tracker/st_extensions.c | 1 +
src/mesa/state_tracker/st_format.c | 5 +--
src/mesa/state_tracker/st_texture.c | 15 ++--
6 files changed, 105 insertions(+), 18 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_texture.c
b/src/mesa/state_tracker/st_atom_texture.c
index 03d0593..ed9a444 100644
--- a/src/mesa/state_tracker/st_atom_texture.c
+++ b/src/mesa/state_tracker/st_atom_texture.c
@@ -192,9 +192,9 @@ get_texture_format_swizzle(const struct st_texture_object
*stObj)
return swizzle_swizzle(stObj-base._Swizzle, tex_swizzle);
}
-
+
/**
- * Return TRUE if the texture's sampler view swizzle is equal to
+ * Return TRUE if the texture's sampler view swizzle is not equal to
* the texture's swizzle.
*
* \param stObj the st texture object,
@@ -214,9 +214,20 @@ check_sampler_swizzle(const struct st_texture_object
*stObj,
static unsigned last_level(struct st_texture_object *stObj)
{
- return MIN2(stObj-base._MaxLevel, stObj-pt-last_level);
+ unsigned ret = MIN2(stObj-base.MinLevel + stObj-base._MaxLevel,
+ stObj-pt-last_level);
+ if (stObj-base.Immutable)
+ ret = MIN2(ret, stObj-base.MinLevel + stObj-base.NumLevels - 1);
+ return ret;
}
+static unsigned last_layer(struct st_texture_object *stObj)
+{
+ if (stObj-base.Immutable)
+ return MIN2(stObj-base.MinLayer + stObj-base.NumLayers - 1,
+ stObj-pt-array_size - 1);
+ return stObj-pt-array_size - 1;
+}
static struct pipe_sampler_view *
st_create_texture_sampler_view_from_stobj(struct pipe_context *pipe,
@@ -249,9 +260,13 @@ st_create_texture_sampler_view_from_stobj(struct
pipe_context *pipe,
templ.u.buf.first_element = f;
templ.u.buf.last_element = f + (n - 1);
} else {
- templ.u.tex.first_level = stObj-base.BaseLevel;
+ templ.u.tex.first_level = stObj-base.MinLevel + stObj-base.BaseLevel;
templ.u.tex.last_level = last_level(stObj);
assert(templ.u.tex.first_level = templ.u.tex.last_level);
+ templ.u.tex.first_layer = stObj-base.MinLayer;
+ templ.u.tex.last_layer = last_layer(stObj);
+ assert(templ.u.tex.first_layer = templ.u.tex.last_layer);
+ templ.target = gl_target_to_pipe(stObj-base.Target);
}
if (swizzle != SWIZZLE_NOOP) {
@@ -287,8 +302,11 @@ st_get_texture_sampler_view_from_stobj(struct st_context
*st,
if (*sv) {
if (check_sampler_swizzle(stObj, *sv) ||
(format != (*sv)-format) ||
- stObj-base.BaseLevel != (*sv)-u.tex.first_level ||
- last_level(stObj) != (*sv)-u.tex.last_level) {
+ gl_target_to_pipe(stObj-base.Target) != (*sv)-target ||
+ stObj-base.MinLevel + stObj-base.BaseLevel !=
(*sv)-u.tex.first_level ||
+ last_level(stObj) != (*sv)-u.tex.last_level ||
+ stObj-base.MinLayer != (*sv)-u.tex.first_layer ||
+ last_layer(stObj) != (*sv)-u.tex.last_layer) {
pipe_sampler_view_reference(sv, NULL);
}
}
diff --git a/src/mesa/state_tracker/st_cb_fbo.c
b/src/mesa/state_tracker/st_cb_fbo.c
index 7cfd3da..470ab27 100644
--- a/src/mesa/state_tracker/st_cb_fbo.c
+++ b/src/mesa/state_tracker/st_cb_fbo.c
@@ -450,6 +450,16 @@ st_update_renderbuffer_surface(struct st_context *st,
last_layer = strb-rtt_face + strb-rtt_slice;
}
+ /* Adjust for texture views */
+ if (strb-is_rtt) {
+ struct gl_texture_object *tex = strb-Base.TexImage-TexObject;
+ first_layer += tex-MinLayer;
+ if (!strb-rtt_layered)
+ last_layer += tex-MinLayer;
+ else
+ last_layer = MIN2(first_layer + tex-NumLayers - 1, last_layer);
+ }
+
if (!strb-surface ||
strb-surface-texture-nr_samples != strb-Base.NumSamples ||
strb-surface-format != format ||
diff --git a/src/mesa/state_tracker/st_cb_texture.c
b/src/mesa/state_tracker/st_cb_texture.c
index ad14bd9..dfa188a 100644
--- a/src/mesa/state_tracker/st_cb_texture.c
+++ b/src/mesa/state_tracker/st_cb_texture.c
@@ -829,12 +829,12 @@ st_TexSubImage(struct gl_context *ctx, GLuint dims,
blit.src.level = 0;
blit.src.format = src_format;
blit.dst.resource = dst;
- blit.dst.level = stObj-pt != stImage-pt ? 0 : texImage-Level;
+ blit.dst.level = stObj-pt != stImage-pt ? 0 :
texImage-TexObject-MinLevel + texImage-Level;
blit.dst.format = dst_format;
blit.src.box.x =
Re: [Mesa-dev] [PATCH v2 2/4] gallium: add a texture target to sampler view and a CAP to use it
Am 21.08.2014 19:39, schrieb Ilia Mirkin: On Thu, Aug 21, 2014 at 1:35 PM, Roland Scheidegger srol...@vmware.com wrote: Am 21.08.2014 04:42, schrieb Ilia Mirkin: This allows a sampler view to have a different texture target than the underlying resource. This will be used to implement the type casting between 2d arrays and cube maps as specified in ARB_texture_view. Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- src/gallium/auxiliary/util/u_sampler.c | 1 + src/gallium/docs/source/screen.rst | 3 +++ src/gallium/drivers/freedreno/freedreno_screen.c | 1 + src/gallium/drivers/i915/i915_screen.c | 1 + src/gallium/drivers/ilo/ilo_screen.c | 1 + src/gallium/drivers/llvmpipe/lp_screen.c | 1 + src/gallium/drivers/nouveau/nv30/nv30_screen.c | 1 + src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 + src/gallium/drivers/nouveau/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/si_pipe.c | 1 + src/gallium/drivers/softpipe/sp_screen.c | 1 + src/gallium/drivers/svga/svga_screen.c | 1 + src/gallium/drivers/vc4/vc4_screen.c | 1 + src/gallium/include/pipe/p_defines.h | 1 + src/gallium/include/pipe/p_state.h | 1 + 17 files changed, 19 insertions(+) diff --git a/src/gallium/auxiliary/util/u_sampler.c b/src/gallium/auxiliary/util/u_sampler.c index 227641b..86799fd 100644 --- a/src/gallium/auxiliary/util/u_sampler.c +++ b/src/gallium/auxiliary/util/u_sampler.c @@ -45,6 +45,7 @@ default_template(struct pipe_sampler_view *view, /* XXX: Check if format is compatible with texture-format. */ + view-target = texture-target; view-format = format; view-u.tex.first_level = 0; view-u.tex.last_level = texture-last_level; diff --git a/src/gallium/docs/source/screen.rst b/src/gallium/docs/source/screen.rst index eee254e..8feeb56 100644 --- a/src/gallium/docs/source/screen.rst +++ b/src/gallium/docs/source/screen.rst @@ -225,6 +225,9 @@ The integer capabilities: memory and GART. * ``PIPE_CAP_CONDITIONAL_RENDER_INVERTED``: Whether the driver supports inverted condition for conditional rendering. +* ``PIPE_CAP_SAMPLER_VIEW_TARGET``: Whether the sampler view's target can be + different than the underlying resource's. This can happen when casting + between 2d array and cube map (array) textures. I'd like to see some more precise language, because even if the difference between array and non-array textures may seem trivial and not matter much usually, it can happen too. Just a minor nitpick, though. Happy to provide any language you deem appropriate. Perhaps only some differences need to be handled? I guess even nouveau wouldn't be particularly happy if you tried to cast a 3d texture to a cube map because of how levels work. Well maybe just say something like for casting targets need to be compatible as defined by ARB_texture_view (for instance 2d array - cube). Clearly noone allows casting along the dimension axis. Roland .. _pipe_capf: diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c b/src/gallium/drivers/freedreno/freedreno_screen.c index ab1a740..165ec8d 100644 --- a/src/gallium/drivers/freedreno/freedreno_screen.c +++ b/src/gallium/drivers/freedreno/freedreno_screen.c @@ -218,6 +218,7 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_DRAW_INDIRECT: case PIPE_CAP_TGSI_FS_FINE_DERIVATIVE: case PIPE_CAP_CONDITIONAL_RENDER_INVERTED: + case PIPE_CAP_SAMPLER_VIEW_TARGET: return 0; /* Stream output. */ diff --git a/src/gallium/drivers/i915/i915_screen.c b/src/gallium/drivers/i915/i915_screen.c index 40976b3..4b70abe 100644 --- a/src/gallium/drivers/i915/i915_screen.c +++ b/src/gallium/drivers/i915/i915_screen.c @@ -234,6 +234,7 @@ i915_get_param(struct pipe_screen *screen, enum pipe_cap cap) case PIPE_CAP_BUFFER_MAP_PERSISTENT_COHERENT: case PIPE_CAP_DRAW_INDIRECT: case PIPE_CAP_TGSI_FS_FINE_DERIVATIVE: + case PIPE_CAP_SAMPLER_VIEW_TARGET: return 0; case PIPE_CAP_MIN_MAP_BUFFER_ALIGNMENT: diff --git a/src/gallium/drivers/ilo/ilo_screen.c b/src/gallium/drivers/ilo/ilo_screen.c index 15658da..9200f55 100644 --- a/src/gallium/drivers/ilo/ilo_screen.c +++ b/src/gallium/drivers/ilo/ilo_screen.c @@ -436,6 +436,7 @@ ilo_get_param(struct pipe_screen *screen, enum pipe_cap param) case PIPE_CAP_DRAW_INDIRECT: case PIPE_CAP_TGSI_FS_FINE_DERIVATIVE: case PIPE_CAP_CONDITIONAL_RENDER_INVERTED: + case PIPE_CAP_SAMPLER_VIEW_TARGET: return 0; case PIPE_CAP_VENDOR_ID: diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c b/src/gallium/drivers/llvmpipe/lp_screen.c index 2a6e673..b10ddfb 100644 ---
Re: [Mesa-dev] [PATCH 02/16] glsl/linker: pass through the is_intrinsic flag
On Fri, Aug 15, 2014 at 5:12 PM, Connor Abbott cwabbo...@gmail.com wrote:
This flag was set to true for the atomic counter intrinsics, but it
never got plumbed through the linker, so by the time it got to the
backends it would always be set to the false. The current i965 backend
code doesn't use is_intrinsic, so this should not change any existing
code, but it's useful for codepaths that want to distinguish between
intrinsics and non-intrinsics without using strcmp.
Signed-off-by: Connor Abbott connor.abb...@intel.com
---
src/glsl/link_functions.cpp | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/glsl/link_functions.cpp b/src/glsl/link_functions.cpp
index 2ce9609..36695ce 100644
--- a/src/glsl/link_functions.cpp
+++ b/src/glsl/link_functions.cpp
@@ -154,6 +154,8 @@ public:
linked_sig-replace_parameters(formal_parameters);
+ linked_sig-is_intrinsic = sig-is_intrinsic;
+
if (sig-is_defined) {
foreach_in_list(const ir_instruction, original, sig-body) {
ir_instruction *copy = original-clone(linked, ht);
--
1.9.3
R-b and committed.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r600/compute: Don't leak compute pool item_list/unallocated_list
v2: Change to C-style comments and fix indentation Signed-off-by: Aaron Watry awa...@gmail.com --- src/gallium/drivers/r600/compute_memory_pool.c | 5 + 1 file changed, 5 insertions(+) diff --git a/src/gallium/drivers/r600/compute_memory_pool.c b/src/gallium/drivers/r600/compute_memory_pool.c index 9324b84..82de9cd 100644 --- a/src/gallium/drivers/r600/compute_memory_pool.c +++ b/src/gallium/drivers/r600/compute_memory_pool.c @@ -95,6 +95,11 @@ void compute_memory_pool_delete(struct compute_memory_pool* pool) pool-screen-b.b.resource_destroy((struct pipe_screen *) pool-screen, (struct pipe_resource *)pool-bo); } + /* In theory, all of the items were freed in compute_memory_free. + Just delete the list heads */ + free(pool-item_list); + free(pool-unallocated_list); + /* And then the pool itself */ free(pool); } -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r600g/compute: Don't leak cbufs in compute state
Walk the array of cbufs backwards and free all of them.
v2: Change to C-style comments and fix indentation
Signed-off-by: Aaron Watry awa...@gmail.com
---
src/gallium/drivers/r600/evergreen_compute.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/src/gallium/drivers/r600/evergreen_compute.c
index 38b78c7..510d9a3 100644
--- a/src/gallium/drivers/r600/evergreen_compute.c
+++ b/src/gallium/drivers/r600/evergreen_compute.c
@@ -240,6 +240,15 @@ void evergreen_delete_compute_state(struct pipe_context
*ctx, void* state)
FREE(shader-kernels);
+ if (shader-ctx){
+ struct pipe_framebuffer_state *fb_state =
shader-ctx-framebuffer.state;
+ for (int i = fb_state-nr_cbufs - 1; fb_state-nr_cbufs 0 ;
i--){
+ shader-ctx-b.b.surface_destroy(ctx,
fb_state-cbufs[i]);
+ fb_state-cbufs[i] = NULL;
+ fb_state-nr_cbufs--;
+ }
+ }
+
#ifdef HAVE_OPENCL
if (shader-llvm_ctx){
LLVMContextDispose(shader-llvm_ctx);
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r600g/compute: Stop leaking CL kernel bytecode/resources
Tested on CEDAR
v2: fix indentation
Signed-off-by: Aaron Watry awa...@gmail.com
---
src/gallium/drivers/r600/evergreen_compute.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/src/gallium/drivers/r600/evergreen_compute.c
index 510d9a3..61446f6 100644
--- a/src/gallium/drivers/r600/evergreen_compute.c
+++ b/src/gallium/drivers/r600/evergreen_compute.c
@@ -238,7 +238,18 @@ void evergreen_delete_compute_state(struct pipe_context
*ctx, void* state)
if (!shader)
return;
- FREE(shader-kernels);
+ if (shader-kernels) {
+ for (int i = 0; i shader-num_kernels; i++) {
+ if (shader-kernels[i].code_bo) {
+ pipe_resource_reference(
+ (struct pipe_resource**)
shader-kernels[i].code_bo,
+ NULL
+ );
+ }
+ FREE(shader-kernels[i].bc.bytecode);
+ }
+ FREE(shader-kernels);
+ }
if (shader-ctx){
struct pipe_framebuffer_state *fb_state =
shader-ctx-framebuffer.state;
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] aux/pipe_loader: Don't leak dlerror string on dlopen failure
dlopen allocates a string on dlopen failure which is retrieved via dlerror. In
order to free that string, you need to retrieve and then free it.
In order to keep things legit the windows/other util_dl_error paths allocate
and then copy their error message into a buffer as well.
Signed-off-by: Aaron Watry awa...@gmail.com
CC: Ilia Mirkin imir...@alum.mit.edu
v3: Switch comment to C-Style
v2: Use strdup instead of calloc/strcpy
---
src/gallium/auxiliary/pipe-loader/pipe_loader.c | 5 +
src/gallium/auxiliary/util/u_dl.c | 4 ++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader.c
b/src/gallium/auxiliary/pipe-loader/pipe_loader.c
index 8e79f85..7a4e0b1 100644
--- a/src/gallium/auxiliary/pipe-loader/pipe_loader.c
+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader.c
@@ -25,6 +25,8 @@
*
**/
+#include dlfcn.h
+
#include pipe_loader_priv.h
#include util/u_inlines.h
@@ -101,6 +103,9 @@ pipe_loader_find_module(struct pipe_loader_device *dev,
if (lib) {
return lib;
}
+
+ /* Retrieve the dlerror() str so that it can be freed properly */
+ FREE(util_dl_error());
}
}
diff --git a/src/gallium/auxiliary/util/u_dl.c
b/src/gallium/auxiliary/util/u_dl.c
index aca435d..00c4d7c 100644
--- a/src/gallium/auxiliary/util/u_dl.c
+++ b/src/gallium/auxiliary/util/u_dl.c
@@ -87,8 +87,8 @@ util_dl_error(void)
#if defined(PIPE_OS_UNIX)
return dlerror();
#elif defined(PIPE_OS_WINDOWS)
- return unknown error;
+ return strdup(unknown error);
#else
- return unknown error;
+ return strdup(unknown error);
#endif
}
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] gallium/targets: Haiku, Fix some improper type warnings
---
.../targets/haiku-softpipe/GalliumFramebuffer.cpp |2 +-
.../targets/haiku-softpipe/SoftwareRenderer.cpp|2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/targets/haiku-softpipe/GalliumFramebuffer.cpp
b/src/gallium/targets/haiku-softpipe/GalliumFramebuffer.cpp
index f367d9d..84c8bd2 100644
--- a/src/gallium/targets/haiku-softpipe/GalliumFramebuffer.cpp
+++ b/src/gallium/targets/haiku-softpipe/GalliumFramebuffer.cpp
@@ -93,7 +93,7 @@ hgl_framebuffer_validate(struct st_context_iface* stctx,
if (context-stVisual context-manager context-manager-screen) {
TRACE(%s: Updating resources\n, __func__);
- int i;
+ unsigned i;
for (i = 0; i count; i++) {
enum pipe_format format = PIPE_FORMAT_NONE;
unsigned bind = 0;
diff --git a/src/gallium/targets/haiku-softpipe/SoftwareRenderer.cpp
b/src/gallium/targets/haiku-softpipe/SoftwareRenderer.cpp
index 9d85b8d..0ae9e52 100644
--- a/src/gallium/targets/haiku-softpipe/SoftwareRenderer.cpp
+++ b/src/gallium/targets/haiku-softpipe/SoftwareRenderer.cpp
@@ -355,7 +355,7 @@ SoftwareRenderer::_AllocateBitmap()
return;
}
- TRACE(%s: New bitmap size: %d x %d\n, __func__,
+ TRACE(%s: New bitmap size: %ld x %ld\n, __func__,
fBitmap-Bounds().IntegerWidth(),
fBitmap-Bounds().IntegerHeight());
fContextObj-ResizeViewport(fWidth, fHeight);
--
1.7.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] gallium/targets: Clean up Haiku softpipe renderer visual
* Drop creating gl_config first as it's only really used
to create the state tracker visual.
---
.../targets/haiku-softpipe/GalliumContext.cpp | 196 ++--
.../targets/haiku-softpipe/GalliumContext.h|2 +
2 files changed, 96 insertions(+), 102 deletions(-)
diff --git a/src/gallium/targets/haiku-softpipe/GalliumContext.cpp
b/src/gallium/targets/haiku-softpipe/GalliumContext.cpp
index d6b5f85..e64ea65 100644
--- a/src/gallium/targets/haiku-softpipe/GalliumContext.cpp
+++ b/src/gallium/targets/haiku-softpipe/GalliumContext.cpp
@@ -69,70 +69,6 @@ hgl_viewport(struct gl_context* glContext)
}
-static st_visual*
-hgl_fill_st_visual(gl_config* glVisual)
-{
- struct st_visual* stVisual = CALLOC_STRUCT(st_visual);
- if (!stVisual) {
- ERROR(%s: Couldn't allocate st_visual\n, __func__);
- return NULL;
- }
-
- // Determine color format
- if (glVisual-redBits == 8) {
- if (glVisual-alphaBits == 8)
- stVisual-color_format = PIPE_FORMAT_A8R8G8B8_UNORM;
- else
- stVisual-color_format = PIPE_FORMAT_X8R8G8B8_UNORM;
- } else {
- // TODO: I think this should be RGB vs BGR
- stVisual-color_format = PIPE_FORMAT_B5G6R5_UNORM;
- }
-
- // Determine depth stencil format
- switch (glVisual-depthBits) {
- default:
- case 0:
- stVisual-depth_stencil_format = PIPE_FORMAT_NONE;
- break;
- case 16:
- stVisual-depth_stencil_format = PIPE_FORMAT_Z16_UNORM;
- break;
- case 24:
- if (glVisual-stencilBits == 0) {
- stVisual-depth_stencil_format =
PIPE_FORMAT_X8Z24_UNORM;
- } else {
- stVisual-depth_stencil_format =
PIPE_FORMAT_S8_UINT_Z24_UNORM;
- }
- break;
- case 32:
- stVisual-depth_stencil_format = PIPE_FORMAT_Z32_UNORM;
- break;
- }
-
- stVisual-accum_format = (glVisual-haveAccumBuffer)
- ? PIPE_FORMAT_R16G16B16A16_SNORM : PIPE_FORMAT_NONE;
-
- stVisual-buffer_mask |= ST_ATTACHMENT_FRONT_LEFT_MASK;
- stVisual-render_buffer = ST_ATTACHMENT_FRONT_LEFT;
- if (glVisual-doubleBufferMode) {
- stVisual-buffer_mask |= ST_ATTACHMENT_BACK_LEFT_MASK;
- stVisual-render_buffer = ST_ATTACHMENT_BACK_LEFT;
- }
-
- if (glVisual-stereoMode) {
- stVisual-buffer_mask |= ST_ATTACHMENT_FRONT_RIGHT_MASK;
- if (glVisual-doubleBufferMode)
- stVisual-buffer_mask |= ST_ATTACHMENT_BACK_RIGHT_MASK;
- }
-
- if (glVisual-haveDepthBuffer || glVisual-haveStencilBuffer)
- stVisual-buffer_mask |= ST_ATTACHMENT_DEPTH_STENCIL_MASK;
-
- return stVisual;
-}
-
-
static int
hook_stm_get_param(struct st_manager *smapi, enum st_manager_param param)
{
@@ -184,6 +120,95 @@ GalliumContext::~GalliumContext()
}
+struct st_visual*
+GalliumContext::CreateVisual()
+{
+ struct st_visual* visual = CALLOC_STRUCT(st_visual);
+ if (!visual) {
+ ERROR(%s: Couldn't allocate st_visual\n, __func__);
+ return NULL;
+ }
+
+ // Calculate visual configuration
+ const GLboolean rgbFlag = ((fOptions BGL_INDEX) == 0);
+ const GLboolean alphaFlag = ((fOptions BGL_ALPHA) == BGL_ALPHA);
+ const GLboolean dblFlag = ((fOptions BGL_DOUBLE) ==
BGL_DOUBLE);
+ const GLboolean stereoFlag = false;
+ const GLint depth = (fOptions BGL_DEPTH) ? 24 :
0;
+ const GLint stencil = (fOptions BGL_STENCIL) ? 8
: 0;
+ const GLint accum = (fOptions BGL_ACCUM) ? 16 :
0;
+ const GLint red = rgbFlag ? 8 : 5;
+ const GLint green = rgbFlag ? 8 : 5;
+ const GLint blue= rgbFlag ? 8 : 5;
+ const GLint alpha = alphaFlag ? 8 : 0;
+
+ TRACE(rgb :\t%d\n, (bool)rgbFlag);
+ TRACE(alpha:\t%d\n, (bool)alphaFlag);
+ TRACE(dbl :\t%d\n, (bool)dblFlag);
+ TRACE(stereo :\t%d\n, (bool)stereoFlag);
+ TRACE(depth:\t%d\n, depth);
+ TRACE(stencil :\t%d\n, stencil);
+ TRACE(accum:\t%d\n, accum);
+ TRACE(red :\t%d\n, red);
+ TRACE(green:\t%d\n, green);
+ TRACE(blue :\t%d\n, blue);
+ TRACE(alpha:\t%d\n, alpha);
+
+ // Determine color format
+ if (red == 8) {
+ if (alpha == 8)
+ visual-color_format = PIPE_FORMAT_A8R8G8B8_UNORM;
+ else
+
Re: [Mesa-dev] [PATCH 1/2] gallium/targets: Clean up Haiku softpipe renderer visual
On , Alexander von Gluck IV wrote:
* Drop creating gl_config first as it's only really used
to create the state tracker visual.
---
.../targets/haiku-softpipe/GalliumContext.cpp | 196
++--
.../targets/haiku-softpipe/GalliumContext.h|2 +
2 files changed, 96 insertions(+), 102 deletions(-)
if (!context-draw || !context-read) {
ERROR(%s: Problem allocating framebuffer!\n, __func__);
- _mesa_destroy_visual(glVisual);
+ //FREE(context-stVisual);
return -1;
}
Whoops, without commenting out the FREE. I was debugging a crash.
-- Alex
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl: uniform sampler should occupy 1 location
--- If samplers occupy zero locations we can run into a lot of issues. See #82921. I briefly tested this with my own code (which was previously crashing and misbehaving) and also ran other apps and everything seems to work fine. I'm not used to contributing code in this fashion, so please forgive me if I'm making some mistake. Thanks. src/glsl/glsl_types.cpp | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/glsl/glsl_types.cpp b/src/glsl/glsl_types.cpp index 66e9b13..cc05193 100644 --- a/src/glsl/glsl_types.cpp +++ b/src/glsl/glsl_types.cpp @@ -691,6 +691,8 @@ glsl_type::uniform_locations() const return size; case GLSL_TYPE_ARRAY: return this-length * this-fields.array-uniform_locations(); + case GLSL_TYPE_SAMPLER: + return 1; default: break; } -- 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
On 21 August 2014 19:10, Henri Verbeet hverb...@gmail.com wrote: On 21 August 2014 04:56, Michel Dänzer mic...@daenzer.net wrote: On 21.08.2014 04:29, Henri Verbeet wrote: For whatever it's worth, I have been avoiding radeonsi in part because of the LLVM dependency. Some of the other issues already mentioned aside, I also think it makes it just painful to do bisects over moderate/longer periods of time. More painful, sure, but not too bad IME. In particular, if you know the regression is in Mesa, you can always use a stable release of LLVM for the bisect. You only need to change the --with-llvm-prefix= parameter to Mesa's configure for that. Of course, it could still be mildly painful if you need to go so far back that the current stable LLVM release wasn't supported yet. But how often does that happen? Very rarely for me. Sure, it's not impossible, but is that really the kind of process you want users to go through when bisecting a regression? Perhaps throw in building 32-bit versions of both Mesa and LLVM on 64-bit as well if they want to run 32-bit applications. Without LLVM, I'm not sure there would be a driver you could avoid. :) R600g didn't really exist either, and that one seems to have worked out fine. I think in a large part because of work done by Jerome and Dave in the early days, but regardless. From what I've seen from SI, I don't think radeonsi needed to be a separate driver to start with, and while its ISA is certainly different from R600-Cayman, it doesn't particularly strike me as much harder to work with. Back to the more immediate topic though, I think think that on occasion the discussion is framed as Is there any reason using LLVM IR wouldn't work?, while it would perhaps be more appropriate to think of as Would using LLVM IR provide enough advantages to justify adding a LLVM dependency to core Mesa?. Could we use an llvm compatible IR? is also a question I'd like to see answered. Dave. ___ 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 Thu, Aug 21, 2014 at 7:36 PM, Dave Airlie airl...@gmail.com wrote: On 21 August 2014 19:10, Henri Verbeet hverb...@gmail.com wrote: On 21 August 2014 04:56, Michel Dänzer mic...@daenzer.net wrote: On 21.08.2014 04:29, Henri Verbeet wrote: For whatever it's worth, I have been avoiding radeonsi in part because of the LLVM dependency. Some of the other issues already mentioned aside, I also think it makes it just painful to do bisects over moderate/longer periods of time. More painful, sure, but not too bad IME. In particular, if you know the regression is in Mesa, you can always use a stable release of LLVM for the bisect. You only need to change the --with-llvm-prefix= parameter to Mesa's configure for that. Of course, it could still be mildly painful if you need to go so far back that the current stable LLVM release wasn't supported yet. But how often does that happen? Very rarely for me. Sure, it's not impossible, but is that really the kind of process you want users to go through when bisecting a regression? Perhaps throw in building 32-bit versions of both Mesa and LLVM on 64-bit as well if they want to run 32-bit applications. Without LLVM, I'm not sure there would be a driver you could avoid. :) R600g didn't really exist either, and that one seems to have worked out fine. I think in a large part because of work done by Jerome and Dave in the early days, but regardless. From what I've seen from SI, I don't think radeonsi needed to be a separate driver to start with, and while its ISA is certainly different from R600-Cayman, it doesn't particularly strike me as much harder to work with. Back to the more immediate topic though, I think think that on occasion the discussion is framed as Is there any reason using LLVM IR wouldn't work?, while it would perhaps be more appropriate to think of as Would using LLVM IR provide enough advantages to justify adding a LLVM dependency to core Mesa?. Could we use an llvm compatible IR? is also a question I'd like to see answered. What do you mean by llvm compatible? Do you mean forking their IR inside mesa or just something that's easy to translate back and forth? --Jason Ekstrand ___ 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 22 August 2014 12:46, Jason Ekstrand ja...@jlekstrand.net wrote: On Thu, Aug 21, 2014 at 7:36 PM, Dave Airlie airl...@gmail.com wrote: On 21 August 2014 19:10, Henri Verbeet hverb...@gmail.com wrote: On 21 August 2014 04:56, Michel Dänzer mic...@daenzer.net wrote: On 21.08.2014 04:29, Henri Verbeet wrote: For whatever it's worth, I have been avoiding radeonsi in part because of the LLVM dependency. Some of the other issues already mentioned aside, I also think it makes it just painful to do bisects over moderate/longer periods of time. More painful, sure, but not too bad IME. In particular, if you know the regression is in Mesa, you can always use a stable release of LLVM for the bisect. You only need to change the --with-llvm-prefix= parameter to Mesa's configure for that. Of course, it could still be mildly painful if you need to go so far back that the current stable LLVM release wasn't supported yet. But how often does that happen? Very rarely for me. Sure, it's not impossible, but is that really the kind of process you want users to go through when bisecting a regression? Perhaps throw in building 32-bit versions of both Mesa and LLVM on 64-bit as well if they want to run 32-bit applications. Without LLVM, I'm not sure there would be a driver you could avoid. :) R600g didn't really exist either, and that one seems to have worked out fine. I think in a large part because of work done by Jerome and Dave in the early days, but regardless. From what I've seen from SI, I don't think radeonsi needed to be a separate driver to start with, and while its ISA is certainly different from R600-Cayman, it doesn't particularly strike me as much harder to work with. Back to the more immediate topic though, I think think that on occasion the discussion is framed as Is there any reason using LLVM IR wouldn't work?, while it would perhaps be more appropriate to think of as Would using LLVM IR provide enough advantages to justify adding a LLVM dependency to core Mesa?. Could we use an llvm compatible IR? is also a question I'd like to see answered. What do you mean by llvm compatible? Do you mean forking their IR inside mesa or just something that's easy to translate back and forth? Importing/forking the llvm IR code with a different symbol set, and trying to not intentionally be incompatible with their llvm. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 00/68] Broadwell 48b addressing and prelocations (no relocs)
The primary goal of these patches is to introduce what I've started calling, prelocations on Broadwell. A prelocation is like a relocation, except not. When a GPU client specifies a prelocation, it is instructing the kernel where in the GPU address the buffer should be mapped. The mechanic works very similarly to a relocation except it uses the execbuffer object to obtain the offset, and bind if needed. If a GPU client uses only prelocations, the relocation process can be entirely skipped. This sounds like a big win initially, but realistically with full PPGTT and 48b address space it's unlikely to noticeably improve anything. Doing this work leaves the address space allocation up to libc/malloc [1] instead of drm_mm which I believe has some upside due to the hits on creating new VMAs. Not specific to prelocations, dynamic page table allocations by themselves can save measurable memory on systems running multiple GPU clients. As previously mentioned, this kind of thing is needed for OCL 2.0 SVM. One other advantage I've discussed with Ken... [2]. The difficult part to enable this [for 64b platforms] is supporting the 48b address space. As mentioned in previous versions of this cover letter, and my blog post [3], it's not feasible to allocate the entire 48b address space's page tables. Dynamic page table allocation and teardown required a lot of plumbing and rework, and to make the interfaces as neat as possible, I also had to put a good deal of work into GEN7 PPGTT well. The other really difficult part is taking the malloc'd memory and turning it into GPU usable pages. Luckily, Chris already did that for me with userptr, so I simply reused his work. The kernel patches are lightly tested at best. Previous iterations of this series were more thoroughly tested, but enough has changed since then that I would assume the code is unstable. If miraculously it is almost stable, there are still a lot of cosmetic things to clean up, and a performance optimization to reduce re-mapping already mapped objects. I started on a patch to do this but ran into too many stability problems (See Optimize PDP loads from previous posts). It's likely memory leaks are introduced with the dynamic page tables; plugging those would nice. One could also implement the reaper I refer to in the comments. With the kernel prelocation support are the libdrm patches, an intel-gpu-tools test, and a mesa patch. Some parts of the code are in rough shape, and were meant for demonstration only. The userspace components in particular were mostly meant as sample code. [4] The series is fundamental 5 parts with some bleeding between 2-3, and 3-4. 1. [00-18] Provide fixes to make a stable branch for test with full PPGTT. I've previously posted this as a separate series. In the meanwhile, many similar fixes have gone in, and some of these may be dropped. So this is mostly here for completeness. 2. [19-42] Rework code to avoid as much future churn as possible. Nothing special here. Some of this is arguably #3. 3. [43-46] Make page table allocations dynamic. I tried to keep this generic, but since the current code supported very specific page table depths, it's really mostly GEN7. 4. [47-67] GEN8 dynamic page table support with 64b page table support. This was very hard to split up, and is definitely the majority of the work. 5. [68] A basic SVM interface. I opted not to use create2 IOCTL since there are patches for that already, and I wanted to have something that's as reusable as possible. X. the rest are workaround/libdrm/mesa/igt Kernel: http://cgit.freedesktop.org/~bwidawsk/drm-intel/log/?h=prelocate libdrm: http://cgit.freedesktop.org/~bwidawsk/drm/log/?h=prelocate mesa: http://cgit.freedesktop.org/~bwidawsk/mesa/log/?h=prelocate IGT: http://cgit.freedesktop.org/~bwidawsk/intel-gpu-tools/log/?h=prelocate Final thoughts: * Due to time pressure, the ability to go back and test on GEN7 was lost. The original patches I posted back in March did work fine on GEN7, but I cannot speak to the quality now. That said, I did the work, so I figured I may as well provide it. For the sake of progress, someone should test/fix GEN7, or simply drop the GEN7 support. * Broadwell is currently hanging with this patch series when I run piglit. I have gone through plenty of software bugs, and this current hang is baffling. Therefore I think it makes sense to either parameterize, or CONFIG_ dynamic page table allocations until that's solved. * Again on the stability, there are a lot of extra flushes introduced as a result of this series. I believe if we can figure out the case of some of these issues, we can remove some flushes. * I haven't tested aliasing PPGTT only in a while. Someone should do that. * I'll bet 32b is broken. * A lot of issues I had were related to the complexities when dealing with legacy contexts. It's possible, and I am hopeful that with execlists these issues go away, and so do the hangs. * The patches have been rebased SO
[Mesa-dev] [PATCH] i965: First step toward prelocation
This was a quick proof of concept to show the new API for prelocating
buffers.
It needs way more testing, to not ifdef the no-relocs, and to do a
libdrm ABI dep bump.
---
src/mesa/drivers/dri/i965/Makefile.am | 1 +
src/mesa/drivers/dri/i965/brw_performance_monitor.c | 6 +++---
src/mesa/drivers/dri/i965/brw_program.c | 5 +++--
src/mesa/drivers/dri/i965/brw_queryobj.c| 6 +++---
src/mesa/drivers/dri/i965/brw_state_cache.c | 4 ++--
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 3 +++
src/mesa/drivers/dri/i965/intel_batchbuffer.h | 8
7 files changed, 23 insertions(+), 10 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/Makefile.am
b/src/mesa/drivers/dri/i965/Makefile.am
index 5809dc6..4b20d36 100644
--- a/src/mesa/drivers/dri/i965/Makefile.am
+++ b/src/mesa/drivers/dri/i965/Makefile.am
@@ -24,6 +24,7 @@
include Makefile.sources
AM_CFLAGS = \
+-DNO_RELOC \
-I$(top_srcdir)/include \
-I$(top_srcdir)/src/ \
-I$(top_srcdir)/src/mapi \
diff --git a/src/mesa/drivers/dri/i965/brw_performance_monitor.c
b/src/mesa/drivers/dri/i965/brw_performance_monitor.c
index edfa3d2..e30c527 100644
--- a/src/mesa/drivers/dri/i965/brw_performance_monitor.c
+++ b/src/mesa/drivers/dri/i965/brw_performance_monitor.c
@@ -1105,13 +1105,13 @@ brw_begin_perf_monitor(struct gl_context *ctx,
* wasting memory for contexts that don't use performance monitors.
*/
if (!brw-perfmon.bookend_bo) {
- brw-perfmon.bookend_bo = drm_intel_bo_alloc(brw-bufmgr,
+ brw-perfmon.bookend_bo = drm_intel_bo_alloc_wrapper(brw-bufmgr,
OA bookend BO,
BOOKEND_BO_SIZE_BYTES,
64);
}
monitor-oa_bo =
- drm_intel_bo_alloc(brw-bufmgr, perf. monitor OA bo, 4096, 64);
+ drm_intel_bo_alloc_wrapper(brw-bufmgr, perf. monitor OA bo, 4096,
64);
#ifdef DEBUG
/* Pre-filling the BO helps debug whether writes landed. */
drm_intel_bo_map(monitor-oa_bo, true);
@@ -1146,7 +1146,7 @@ brw_begin_perf_monitor(struct gl_context *ctx,
if (monitor_needs_statistics_registers(brw, m)) {
monitor-pipeline_stats_bo =
- drm_intel_bo_alloc(brw-bufmgr, perf. monitor stats bo, 4096, 64);
+ drm_intel_bo_alloc_wrapper(brw-bufmgr, perf. monitor stats bo,
4096, 64);
/* Take starting snapshots. */
snapshot_statistics_registers(brw, monitor, 0);
diff --git a/src/mesa/drivers/dri/i965/brw_program.c
b/src/mesa/drivers/dri/i965/brw_program.c
index d782b4f..74ff40c 100644
--- a/src/mesa/drivers/dri/i965/brw_program.c
+++ b/src/mesa/drivers/dri/i965/brw_program.c
@@ -43,6 +43,7 @@
#include brw_context.h
#include brw_wm.h
+#include intel_batchbuffer.h
static unsigned
get_new_program_id(struct intel_screen *screen)
@@ -242,7 +243,7 @@ brw_get_scratch_bo(struct brw_context *brw,
}
if (!old_bo) {
- *scratch_bo = drm_intel_bo_alloc(brw-bufmgr, scratch bo, size, 4096);
+ *scratch_bo = drm_intel_bo_alloc_wrapper(brw-bufmgr, scratch bo,
size, 4096);
}
}
@@ -265,7 +266,7 @@ void
brw_init_shader_time(struct brw_context *brw)
{
const int max_entries = 4096;
- brw-shader_time.bo = drm_intel_bo_alloc(brw-bufmgr, shader time,
+ brw-shader_time.bo = drm_intel_bo_alloc_wrapper(brw-bufmgr, shader time,
max_entries * SHADER_TIME_STRIDE,
4096);
brw-shader_time.shader_programs = rzalloc_array(brw, struct
gl_shader_program *,
diff --git a/src/mesa/drivers/dri/i965/brw_queryobj.c
b/src/mesa/drivers/dri/i965/brw_queryobj.c
index c053c34..cf5a2a5 100644
--- a/src/mesa/drivers/dri/i965/brw_queryobj.c
+++ b/src/mesa/drivers/dri/i965/brw_queryobj.c
@@ -230,7 +230,7 @@ brw_begin_query(struct gl_context *ctx, struct
gl_query_object *q)
* the system was doing other work, such as running other applications.
*/
drm_intel_bo_unreference(query-bo);
- query-bo = drm_intel_bo_alloc(brw-bufmgr, timer query, 4096, 4096);
+ query-bo = drm_intel_bo_alloc_wrapper(brw-bufmgr, timer query, 4096,
4096);
brw_write_timestamp(brw, query-bo, 0);
break;
@@ -388,7 +388,7 @@ ensure_bo_has_space(struct gl_context *ctx, struct
brw_query_object *query)
brw_queryobj_get_results(ctx, query);
}
- query-bo = drm_intel_bo_alloc(brw-bufmgr, query, 4096, 1);
+ query-bo = drm_intel_bo_alloc_wrapper(brw-bufmgr, query, 4096, 1);
query-last_index = 0;
}
}
@@ -474,7 +474,7 @@ brw_query_counter(struct gl_context *ctx, struct
gl_query_object *q)
assert(q-Target == GL_TIMESTAMP);
drm_intel_bo_unreference(query-bo);
- query-bo = drm_intel_bo_alloc(brw-bufmgr, timestamp query, 4096, 4096);
+ query-bo = drm_intel_bo_alloc_wrapper(brw-bufmgr, timestamp query,
4096, 4096);
[Mesa-dev] [PATCH] glsl: fix uniform location count for opaque types
Signed-off-by: Tapani Pälli tapani.pa...@intel.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82921 --- src/glsl/glsl_types.cpp | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/glsl/glsl_types.cpp b/src/glsl/glsl_types.cpp index 66e9b13..6c42284 100644 --- a/src/glsl/glsl_types.cpp +++ b/src/glsl/glsl_types.cpp @@ -696,9 +696,9 @@ glsl_type::uniform_locations() const } /* The location count for many types match with component_slots() result, -* all expections should be handled above. +* all expections should be handled above. At least 1 slot is consumed. */ - return component_slots(); + return MAX2(1, component_slots()); } bool -- 1.9.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: fix uniform location count for opaque types
Another patch was sent for this bug as well: [PATCH] glsl: uniform sampler should occupy 1 location I don't have any idea what the appropriate fix is, I just wanted to let you know. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: uniform sampler should occupy 1 location
On 08/22/2014 02:25 AM, Micael Dias wrote: --- If samplers occupy zero locations we can run into a lot of issues. See #82921. I briefly tested this with my own code (which was previously crashing and misbehaving) and also ran other apps and everything seems to work fine. I'm not used to contributing code in this fashion, so please forgive me if I'm making some mistake. Thanks. Thanks for the patch, I sent a bit different fix to be sure all possible types will consume at least 1 loc, this is just to be future-proof. src/glsl/glsl_types.cpp | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/glsl/glsl_types.cpp b/src/glsl/glsl_types.cpp index 66e9b13..cc05193 100644 --- a/src/glsl/glsl_types.cpp +++ b/src/glsl/glsl_types.cpp @@ -691,6 +691,8 @@ glsl_type::uniform_locations() const return size; case GLSL_TYPE_ARRAY: return this-length * this-fields.array-uniform_locations(); + case GLSL_TYPE_SAMPLER: + return 1; default: break; } // Tapani ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/clover: Change platform name from Default to Clover
Aaron Watry awa...@gmail.com writes: Signed-off-by: Aaron Watry awa...@gmail.com Reviewed-by: Francisco Jerez curroje...@riseup.net --- src/gallium/state_trackers/clover/api/platform.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/state_trackers/clover/api/platform.cpp b/src/gallium/state_trackers/clover/api/platform.cpp index 81b0854..cf71593 100644 --- a/src/gallium/state_trackers/clover/api/platform.cpp +++ b/src/gallium/state_trackers/clover/api/platform.cpp @@ -61,7 +61,7 @@ clover::GetPlatformInfo(cl_platform_id d_platform, cl_platform_info param, break; case CL_PLATFORM_NAME: - buf.as_string() = Default; + buf.as_string() = Clover; break; case CL_PLATFORM_VENDOR: -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev pgpGZWd5VrYAX.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
