[Mesa-dev] Mesa 10.4 has been branched
Hello list, As you'll notice shortly I have just branched the next release branch 10.4 of the master branch. Additionally I've created and pushed a 10.4-branchpoint tag that should ease people searching through mesa's history. The first release candidate tag be that 10.4.0-rc1 or 10.3.99.901 will follow on Monday based on the yay and nays on the topic. Obviously the tag will go with piglit testing followed by a summary with the results shortly after. As a reminder: Please include both 10.4 and 10.3 if you like your stable patch to be picked up for the two branches. Patches without explicit version will be considered for the 10.3 only. Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: Bump version to 10.5.0-devel.
Signed-off-by: Vinson Lee v...@freedesktop.org --- VERSION | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/VERSION b/VERSION index d43f97a..093d8ba 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -10.4.0-devel +10.5.0-devel -- 1.9.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Fix _mesa_uint_array_min_max linker error.
On 11/15/2014 01:20 AM, Timothy Arceri wrote: On Fri, 2014-11-14 at 22:14 +0330, Siavash Eliasi wrote: You are right. Any suggestions on how to fix this build failure? Using this would fix it but the optimisation would be disabled on clang. Not sure how many people are concerned about this, I don't use clang myself. [1] http://lists.freedesktop.org/archives/mesa-dev/2014-November/070387.html Unfortunately I'm not familiar with autoconf, but I think the magic should happen at configure.ac. I think USE_SSE41 macro should only defined when: 1. SSE4.1 is not permanently disabled (-mno-sse4.1) and 2. target compiler supports generating SSE4.1 code. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Bump version to 10.5.0-devel.
Hi Vinson, I've deliberately omitted the version update, pending the conclusion of the Move mesa version scheme to a more common style ? thread -Emil On 15/11/14 08:50, Vinson Lee wrote: Signed-off-by: Vinson Lee v...@freedesktop.org --- VERSION | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/VERSION b/VERSION index d43f97a..093d8ba 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -10.4.0-devel +10.5.0-devel ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Move mesa version scheme to a more common style ?
On 14 November 2014 16:48, Ilia Mirkin imir...@alum.mit.edu wrote:
On Fri, Nov 14, 2014 at 11:17 AM, Emil Velikov emil.l.veli...@gmail.com
wrote:
On 14/11/14 15:24, Ilia Mirkin wrote:
On Fri, Nov 14, 2014 at 9:39 AM, Emil Velikov emil.l.veli...@gmail.com
wrote:
Hello all,
This is an old question that I had laying around - why doesn't mesa use
a more conventional numbering for the development/rc releases ?
Eg.
mesa 10.4.0-rc1 - 10.3.99.901
mesa 10.4.0-rc2 - 10.3.99.902
...
mesa 10.4.0 - 10.4.0
mesa 10.4.1-rc1 - 10.4.0.901
... you get the idea.
Afaics most freedesktop project use it plus a big hunk of gnome.
Are there any objections if I move to the above format starting with
mesa 10.4-rc1 ? I would appreciate any feedback over the next 2-3 days,
and based on it I'll tag the first RC.
Huh? What's wrong with the current thing? Can I put in an alternate
suggestion of getting the other projects to switch to the mesa (and
linux kernel and wine and many many many other projects) rc version
naming scheme?
To be perfectly honest, I don't think I can think of any (apart from the
kernel and wine) that have a stable branch(es) and use rc. Can you
kindly point me to some or if you have some ideas of a search phrase
that would be appreciated.
Hmmm... well, most projects don't *have* rc's, so it's definitely a
reduced set. But let's see... just thinking about various software I
use and plugging it into my favourite search engine:
Speaking of software that I use, KDE (with all of its glory) uses
identical scheme as the proposed.
emacs: http://lists.gnu.org/archive/html/info-gnu-emacs/2014-10/msg1.html
So it seems that their 9x are the actual rc (relates to the proposal),
while their RC is an actual wake up call - guys test this because I'm
releasing in two days. Also the RC business seems to be a recent
feature as only the last to releases have it.
openssl: https://www.openssl.org/source/ (does -beta1 instead of -rc1,
but same idea)
That software has a special definition of {major,minor,patch} number
:P Yet it justifies your point.
pidgin did beta tags for 2.0, but not for all releases:
https://hg.pidgin.im/pidgin/main/tags
Can not see any stable branch in there. I don't think there is any
master branch either. They have default, which is presumably the same
as master.
BTW, it's not like I'm leaving out ones that use some other scheme...
other ones I looked up just didn't have any such thing at all.
When in Rome... + mesa is considered part of X development = ?
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Move mesa version scheme to a more common style ?
On 14 November 2014 19:50, Ilia Mirkin imir...@alum.mit.edu wrote: On Fri, Nov 14, 2014 at 9:39 AM, Emil Velikov emil.l.veli...@gmail.com wrote: Hello all, This is an old question that I had laying around - why doesn't mesa use a more conventional numbering for the development/rc releases ? Eg. mesa 10.4.0-rc1 - 10.3.99.901 mesa 10.4.0-rc2 - 10.3.99.902 ... mesa 10.4.0 - 10.4.0 Something else that occurred to me -- you want to still make a stable 10.3 release, so 10.3.x will come out after 10.3.99.901? Seems confusing... Not sure I fully understand what the confusing part it is. Can you elaborate ? Perhaps the following examples should clear any of your confusion: 10.3 branch: 10.3.0 10.3.0.901 (10.3.1-rc1) 10.3.0.902 (10.3.1-rc2) // if needed 10.3.1 10.3.1.901 (10.3.2-rc1) 10.3.1.902 (10.3.2-rc2) // if needed ... you get the idea. At the same time Master branch: 10.3.99 (10.4-dev) 10.4.99 (10.5-dev) As you can see things are straight forward, plus as Daniel pointed out, using this approach the version string is actually linear :) -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] Revert mesa: Wrap SSE4.1 code in #ifdef __SSE4_1__.
This reverts commit 8d3f739383fbdf671752fdec707f1c2b9b2aa6a3. In the last commit we've updated our check to determine if the actual code is buildable, rather than if the compiler acknowledges the option. I.e. did anyone provide -mno-sse4.1 vs is my compiler too old. Now this code will never be attemped to be build, in both cases. Confirmed by building mesa with export CFLAGS='-march=native -mno-sse4.1' configure make Cc: Matt Turner matts...@gmail.com Cc: David Heidelberger da...@ixit.cz --- src/mesa/main/streaming-load-memcpy.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/src/mesa/main/streaming-load-memcpy.c b/src/mesa/main/streaming-load-memcpy.c index 8427149..d7147af 100644 --- a/src/mesa/main/streaming-load-memcpy.c +++ b/src/mesa/main/streaming-load-memcpy.c @@ -26,7 +26,6 @@ * */ -#ifdef __SSE4_1__ #include main/macros.h #include main/streaming-load-memcpy.h #include smmintrin.h @@ -84,5 +83,3 @@ _mesa_streaming_load_memcpy(void *restrict dst, void *restrict src, size_t len) memcpy(d, s, len); } } - -#endif -- 2.1.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] configure.ac: roll up a program for the sse4.1 check
So when checking/building sse code we have three possibilities:
1 Old compiler, throws an error when using -msse*
2 New compiler, user disables sse* (-mno-sse*)
3 New compiler, user doesn't disable sse
The original code, added code for #1 but not #2. Later on we patched
around the lack of handling #2 by wrapping the code in __SSE4_1__.
Yet it lead to a missing/undefined symbol in case of #1 or #2, which
might cause an issue for #2 when using the i965 driver.
A bit later we fixed the undefined symbol by using #1, rather than
updating it to handle #2. With this commit we set things straight :)
To top it all up, conventions state that in case of conflicting
(-enable-foo -disable-foo) options, the latter one takes precedence.
Thus we need to make sure to prepend -msse4.1 to CFLAGS in our test.
Cc: Siavash Eliasi siavashser...@gmail.com
Cc: Matt Turner matts...@gmail.com
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
Man this thing is _very_ messy.
Matt from the last hunk it seems that pixman might need fixing. Should
be bother with that, or let people have fun when they hit it :P
-Emil
configure.ac | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 91e111b..9d1835e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -252,7 +252,19 @@ AC_SUBST([VISIBILITY_CXXFLAGS])
dnl
dnl Optional flags, check for compiler support
dnl
-AX_CHECK_COMPILE_FLAG([-msse4.1], [SSE41_SUPPORTED=1], [SSE41_SUPPORTED=0])
+save_CFLAGS=$CFLAGS
+CFLAGS=-msse4.1 $CFLAGS
+AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
+#include mmintrin.h
+#include xmmintrin.h
+#include emmintrin.h
+#include smmintrin.h
+int main () {
+__m128i a = _mm_set1_epi32 (0), b = _mm_set1_epi32 (0), c;
+c = _mm_max_epu32(a, b);
+return 0;
+}]])], SSE41_SUPPORTED=1)
+CFLAGS=$save_CFLAGS
if test x$SSE41_SUPPORTED = x1; then
DEFINES=$DEFINES -DUSE_SSE41
fi
--
2.1.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Move mesa version scheme to a more common style ?
On Sat, Nov 15, 2014 at 6:52 AM, Emil Velikov emil.l.veli...@gmail.com wrote: On 14 November 2014 19:50, Ilia Mirkin imir...@alum.mit.edu wrote: On Fri, Nov 14, 2014 at 9:39 AM, Emil Velikov emil.l.veli...@gmail.com wrote: Hello all, This is an old question that I had laying around - why doesn't mesa use a more conventional numbering for the development/rc releases ? Eg. mesa 10.4.0-rc1 - 10.3.99.901 mesa 10.4.0-rc2 - 10.3.99.902 ... mesa 10.4.0 - 10.4.0 Something else that occurred to me -- you want to still make a stable 10.3 release, so 10.3.x will come out after 10.3.99.901? Seems confusing... Not sure I fully understand what the confusing part it is. Can you elaborate ? Perhaps the following examples should clear any of your confusion: 10.3 branch: 10.3.0 10.3.0.901 (10.3.1-rc1) 10.3.0.902 (10.3.1-rc2) // if needed 10.3.1 10.3.1.901 (10.3.2-rc1) 10.3.1.902 (10.3.2-rc2) // if needed ... you get the idea. At the same time Master branch: 10.3.99 (10.4-dev) So you make this release. One might *think* that the latest 10.3.x is 10.3.99 then. But it's not. Since *after* this release, you'll put out a 10.3.2, which will have fixes that 10.3.99 doesn't have. It makes for a non-linear version number situation which IMO is rather confusing. With the current version numbering scheme that ~every project uses except X.org, it's very clear what the latest release is in a particular line. Also, 10.3.99 has no connection to 10.3 at all, it is in fact much closer to 10.4. This is why it makes sense to call it 10.4-rc1 and not 10.3.x. -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Move mesa version scheme to a more common style ?
I've always found the X.Org versioning scheme unintuitive. This is actually for the first time after ~5 years of contributing to open source graphics that I finally understand how the X versioning works. Granted, I had never been interested in it anyway. If you need to have a web page on x.org that explains it, that alone is an indication that it's too complicated. Marek On Fri, Nov 14, 2014 at 3:39 PM, Emil Velikov emil.l.veli...@gmail.com wrote: Hello all, This is an old question that I had laying around - why doesn't mesa use a more conventional numbering for the development/rc releases ? Eg. mesa 10.4.0-rc1 - 10.3.99.901 mesa 10.4.0-rc2 - 10.3.99.902 ... mesa 10.4.0 - 10.4.0 mesa 10.4.1-rc1 - 10.4.0.901 ... you get the idea. Afaics most freedesktop project use it plus a big hunk of gnome. Are there any objections if I move to the above format starting with mesa 10.4-rc1 ? I would appreciate any feedback over the next 2-3 days, and based on it I'll tag the first RC. The plan is to still keep the branch point later on today, but to push the tag on Monday. Thanks Emil ___ 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 2/2] Revert mesa: Wrap SSE4.1 code in #ifdef __SSE4_1__.
Apply for both patch 1/2 and 2/2. Host: chroot on AMD A3870K Target: AMD TK-55 (compiled with -mno-sse41) I tested chroot cross-compilation and it passed correctly. Tested-by: David Heidelberg da...@ixit.cz On 11/15/2014 06:04 PM, Emil Velikov wrote: This reverts commit 8d3f739383fbdf671752fdec707f1c2b9b2aa6a3. In the last commit we've updated our check to determine if the actual code is buildable, rather than if the compiler acknowledges the option. I.e. did anyone provide -mno-sse4.1 vs is my compiler too old. Now this code will never be attemped to be build, in both cases. Confirmed by building mesa with export CFLAGS='-march=native -mno-sse4.1' configure make Cc: Matt Turner matts...@gmail.com Cc: David Heidelberger da...@ixit.cz --- src/mesa/main/streaming-load-memcpy.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/src/mesa/main/streaming-load-memcpy.c b/src/mesa/main/streaming-load-memcpy.c index 8427149..d7147af 100644 --- a/src/mesa/main/streaming-load-memcpy.c +++ b/src/mesa/main/streaming-load-memcpy.c @@ -26,7 +26,6 @@ * */ -#ifdef __SSE4_1__ #include main/macros.h #include main/streaming-load-memcpy.h #include smmintrin.h @@ -84,5 +83,3 @@ _mesa_streaming_load_memcpy(void *restrict dst, void *restrict src, size_t len) memcpy(d, s, len); } } - -#endif ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] configure.ac: roll up a program for the sse4.1 check
On Sat, Nov 15, 2014 at 12:04 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
So when checking/building sse code we have three possibilities:
1 Old compiler, throws an error when using -msse*
2 New compiler, user disables sse* (-mno-sse*)
3 New compiler, user doesn't disable sse
The original code, added code for #1 but not #2. Later on we patched
around the lack of handling #2 by wrapping the code in __SSE4_1__.
Yet it lead to a missing/undefined symbol in case of #1 or #2, which
might cause an issue for #2 when using the i965 driver.
A bit later we fixed the undefined symbol by using #1, rather than
updating it to handle #2. With this commit we set things straight :)
To top it all up, conventions state that in case of conflicting
(-enable-foo -disable-foo) options, the latter one takes precedence.
Thus we need to make sure to prepend -msse4.1 to CFLAGS in our test.
Cc: Siavash Eliasi siavashser...@gmail.com
Cc: Matt Turner matts...@gmail.com
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
Man this thing is _very_ messy.
Matt from the last hunk it seems that pixman might need fixing. Should
be bother with that, or let people have fun when they hit it :P
-Emil
configure.ac | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 91e111b..9d1835e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -252,7 +252,19 @@ AC_SUBST([VISIBILITY_CXXFLAGS])
dnl
dnl Optional flags, check for compiler support
dnl
-AX_CHECK_COMPILE_FLAG([-msse4.1], [SSE41_SUPPORTED=1], [SSE41_SUPPORTED=0])
+save_CFLAGS=$CFLAGS
+CFLAGS=-msse4.1 $CFLAGS
+AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
+#include mmintrin.h
+#include xmmintrin.h
+#include emmintrin.h
+#include smmintrin.h
+int main () {
+__m128i a = _mm_set1_epi32 (0), b = _mm_set1_epi32 (0), c;
+c = _mm_max_epu32(a, b);
+return 0;
This seems complicated.
(a) Just #include immintrin.h
(b) Is any of this even necessary? how about
int main() { return !__SSE_4_1__; }
+}]])], SSE41_SUPPORTED=1)
+CFLAGS=$save_CFLAGS
if test x$SSE41_SUPPORTED = x1; then
DEFINES=$DEFINES -DUSE_SSE41
fi
--
2.1.3
___
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/2] configure.ac: roll up a program for the sse4.1 check
On Sat, Nov 15, 2014 at 1:13 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Sat, Nov 15, 2014 at 12:04 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
So when checking/building sse code we have three possibilities:
1 Old compiler, throws an error when using -msse*
2 New compiler, user disables sse* (-mno-sse*)
3 New compiler, user doesn't disable sse
The original code, added code for #1 but not #2. Later on we patched
around the lack of handling #2 by wrapping the code in __SSE4_1__.
Yet it lead to a missing/undefined symbol in case of #1 or #2, which
might cause an issue for #2 when using the i965 driver.
A bit later we fixed the undefined symbol by using #1, rather than
updating it to handle #2. With this commit we set things straight :)
To top it all up, conventions state that in case of conflicting
(-enable-foo -disable-foo) options, the latter one takes precedence.
Thus we need to make sure to prepend -msse4.1 to CFLAGS in our test.
Cc: Siavash Eliasi siavashser...@gmail.com
Cc: Matt Turner matts...@gmail.com
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
Man this thing is _very_ messy.
Matt from the last hunk it seems that pixman might need fixing. Should
be bother with that, or let people have fun when they hit it :P
-Emil
configure.ac | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 91e111b..9d1835e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -252,7 +252,19 @@ AC_SUBST([VISIBILITY_CXXFLAGS])
dnl
dnl Optional flags, check for compiler support
dnl
-AX_CHECK_COMPILE_FLAG([-msse4.1], [SSE41_SUPPORTED=1], [SSE41_SUPPORTED=0])
+save_CFLAGS=$CFLAGS
+CFLAGS=-msse4.1 $CFLAGS
+AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
+#include mmintrin.h
+#include xmmintrin.h
+#include emmintrin.h
+#include smmintrin.h
+int main () {
+__m128i a = _mm_set1_epi32 (0), b = _mm_set1_epi32 (0), c;
+c = _mm_max_epu32(a, b);
+return 0;
This seems complicated.
(a) Just #include immintrin.h
(b) Is any of this even necessary? how about
int main() { return !__SSE_4_1__; }
Er, I guess this is a compile check, so more like
#ifndef __SSE_4_1__
#error no sse4.1 support
#endif
int main() { return 0; }
+}]])], SSE41_SUPPORTED=1)
+CFLAGS=$save_CFLAGS
if test x$SSE41_SUPPORTED = x1; then
DEFINES=$DEFINES -DUSE_SSE41
fi
--
2.1.3
___
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/2] configure.ac: roll up a program for the sse4.1 check
On Sat, Nov 15, 2014 at 10:13 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Sat, Nov 15, 2014 at 12:04 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
So when checking/building sse code we have three possibilities:
1 Old compiler, throws an error when using -msse*
2 New compiler, user disables sse* (-mno-sse*)
3 New compiler, user doesn't disable sse
The original code, added code for #1 but not #2. Later on we patched
around the lack of handling #2 by wrapping the code in __SSE4_1__.
Yet it lead to a missing/undefined symbol in case of #1 or #2, which
might cause an issue for #2 when using the i965 driver.
A bit later we fixed the undefined symbol by using #1, rather than
updating it to handle #2. With this commit we set things straight :)
To top it all up, conventions state that in case of conflicting
(-enable-foo -disable-foo) options, the latter one takes precedence.
Thus we need to make sure to prepend -msse4.1 to CFLAGS in our test.
Cc: Siavash Eliasi siavashser...@gmail.com
Cc: Matt Turner matts...@gmail.com
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
Man this thing is _very_ messy.
Matt from the last hunk it seems that pixman might need fixing. Should
be bother with that, or let people have fun when they hit it :P
-Emil
configure.ac | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 91e111b..9d1835e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -252,7 +252,19 @@ AC_SUBST([VISIBILITY_CXXFLAGS])
dnl
dnl Optional flags, check for compiler support
dnl
-AX_CHECK_COMPILE_FLAG([-msse4.1], [SSE41_SUPPORTED=1], [SSE41_SUPPORTED=0])
+save_CFLAGS=$CFLAGS
+CFLAGS=-msse4.1 $CFLAGS
+AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
+#include mmintrin.h
+#include xmmintrin.h
+#include emmintrin.h
+#include smmintrin.h
+int main () {
+__m128i a = _mm_set1_epi32 (0), b = _mm_set1_epi32 (0), c;
+c = _mm_max_epu32(a, b);
+return 0;
This seems complicated.
(a) Just #include immintrin.h
(b) Is any of this even necessary? how about
int main() { return !__SSE_4_1__; }
Checking that you can actually using the intrinsics seens like a good
plan. Pixman's configure.ac has been doing that for a long time. I'd
rather copy that. It's not like we'd save much by not doing it.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] configure.ac: roll up a program for the sse4.1 check
On Sat, Nov 15, 2014 at 9:04 AM, Emil Velikov emil.l.veli...@gmail.com wrote:
So when checking/building sse code we have three possibilities:
1 Old compiler, throws an error when using -msse*
2 New compiler, user disables sse* (-mno-sse*)
3 New compiler, user doesn't disable sse
The original code, added code for #1 but not #2. Later on we patched
around the lack of handling #2 by wrapping the code in __SSE4_1__.
Yet it lead to a missing/undefined symbol in case of #1 or #2, which
might cause an issue for #2 when using the i965 driver.
A bit later we fixed the undefined symbol by using #1, rather than
updating it to handle #2. With this commit we set things straight :)
To top it all up, conventions state that in case of conflicting
(-enable-foo -disable-foo) options, the latter one takes precedence.
Thus we need to make sure to prepend -msse4.1 to CFLAGS in our test.
Cc: Siavash Eliasi siavashser...@gmail.com
Cc: Matt Turner matts...@gmail.com
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
Man this thing is _very_ messy.
Matt from the last hunk it seems that pixman might need fixing. Should
be bother with that, or let people have fun when they hit it :P
I don't know what you mean, specifically.
-Emil
configure.ac | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 91e111b..9d1835e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -252,7 +252,19 @@ AC_SUBST([VISIBILITY_CXXFLAGS])
dnl
dnl Optional flags, check for compiler support
dnl
-AX_CHECK_COMPILE_FLAG([-msse4.1], [SSE41_SUPPORTED=1], [SSE41_SUPPORTED=0])
+save_CFLAGS=$CFLAGS
+CFLAGS=-msse4.1 $CFLAGS
+AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
+#include mmintrin.h
+#include xmmintrin.h
+#include emmintrin.h
+#include smmintrin.h
I think all you need to include is smmintrin.h.
+int main () {
+__m128i a = _mm_set1_epi32 (0), b = _mm_set1_epi32 (0), c;
+c = _mm_max_epu32(a, b);
+return 0;
+}]])], SSE41_SUPPORTED=1)
+CFLAGS=$save_CFLAGS
if test x$SSE41_SUPPORTED = x1; then
DEFINES=$DEFINES -DUSE_SSE41
fi
--
2.1.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] Revert mesa: Wrap SSE4.1 code in #ifdef __SSE4_1__.
On Sat, Nov 15, 2014 at 9:04 AM, Emil Velikov emil.l.veli...@gmail.com wrote: This reverts commit 8d3f739383fbdf671752fdec707f1c2b9b2aa6a3. In the last commit we've updated our check to determine if the actual code is buildable, rather than if the compiler acknowledges the option. I.e. did anyone provide -mno-sse4.1 vs is my compiler too old. Now this code will never be attemped to be build, in both cases. Confirmed by building mesa with export CFLAGS='-march=native -mno-sse4.1' configure make Cc: Matt Turner matts...@gmail.com Cc: David Heidelberger da...@ixit.cz Thanks Emil. Both look good, with some minor comments on patch #1 -- both are Reviewed-by: Matt Turner matts...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] configure.ac: roll up a program for the sse4.1 check
On 15/11/14 18:18, Matt Turner wrote:
On Sat, Nov 15, 2014 at 10:13 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Sat, Nov 15, 2014 at 12:04 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
So when checking/building sse code we have three possibilities:
1 Old compiler, throws an error when using -msse*
2 New compiler, user disables sse* (-mno-sse*)
3 New compiler, user doesn't disable sse
The original code, added code for #1 but not #2. Later on we patched
around the lack of handling #2 by wrapping the code in __SSE4_1__.
Yet it lead to a missing/undefined symbol in case of #1 or #2, which
might cause an issue for #2 when using the i965 driver.
A bit later we fixed the undefined symbol by using #1, rather than
updating it to handle #2. With this commit we set things straight :)
To top it all up, conventions state that in case of conflicting
(-enable-foo -disable-foo) options, the latter one takes precedence.
Thus we need to make sure to prepend -msse4.1 to CFLAGS in our test.
Cc: Siavash Eliasi siavashser...@gmail.com
Cc: Matt Turner matts...@gmail.com
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
Man this thing is _very_ messy.
Matt from the last hunk it seems that pixman might need fixing. Should
be bother with that, or let people have fun when they hit it :P
-Emil
configure.ac | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 91e111b..9d1835e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -252,7 +252,19 @@ AC_SUBST([VISIBILITY_CXXFLAGS])
dnl
dnl Optional flags, check for compiler support
dnl
-AX_CHECK_COMPILE_FLAG([-msse4.1], [SSE41_SUPPORTED=1], [SSE41_SUPPORTED=0])
+save_CFLAGS=$CFLAGS
+CFLAGS=-msse4.1 $CFLAGS
+AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
+#include mmintrin.h
+#include xmmintrin.h
+#include emmintrin.h
+#include smmintrin.h
+int main () {
+__m128i a = _mm_set1_epi32 (0), b = _mm_set1_epi32 (0), c;
+c = _mm_max_epu32(a, b);
+return 0;
This seems complicated.
Ilia, did you really mean complicated or you're having a thing for me :)
Excessive ? Perhaps, but as Matt mentioned, actually checking one of the
functions you're going to use does not hurt.
(a) Just #include immintrin.h
(b) Is any of this even necessary? how about
int main() { return !__SSE_4_1__; }
Checking that you can actually using the intrinsics seens like a good
plan. Pixman's configure.ac has been doing that for a long time. I'd
rather copy that. It's not like we'd save much by not doing it.
That's where I drew the inspiration.
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] configure.ac: roll up a program for the sse4.1 check
Tested on Core2 Q9550, using -march=native with and without
-mno-sse4.1flag. It works perfect :)
Also David Heidelberg kindly tested the patch which permanently enables
optimized code paths if supported by target machine and it was okay.
http://patchwork.freedesktop.org/patch/36488/
And a small improvement to your patch, I think including smmintrin.h
or the all-in-one alternative immintrin.h should be enough.
Best regards,
Siavash Eliasi.
On 11/15/2014 08:34 PM, Emil Velikov wrote:
So when checking/building sse code we have three possibilities:
1 Old compiler, throws an error when using -msse*
2 New compiler, user disables sse* (-mno-sse*)
3 New compiler, user doesn't disable sse
The original code, added code for #1 but not #2. Later on we patched
around the lack of handling #2 by wrapping the code in __SSE4_1__.
Yet it lead to a missing/undefined symbol in case of #1 or #2, which
might cause an issue for #2 when using the i965 driver.
A bit later we fixed the undefined symbol by using #1, rather than
updating it to handle #2. With this commit we set things straight :)
To top it all up, conventions state that in case of conflicting
(-enable-foo -disable-foo) options, the latter one takes precedence.
Thus we need to make sure to prepend -msse4.1 to CFLAGS in our test.
Cc: Siavash Eliasi siavashser...@gmail.com
Cc: Matt Turner matts...@gmail.com
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
Man this thing is _very_ messy.
Matt from the last hunk it seems that pixman might need fixing. Should
be bother with that, or let people have fun when they hit it :P
-Emil
configure.ac | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 91e111b..9d1835e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -252,7 +252,19 @@ AC_SUBST([VISIBILITY_CXXFLAGS])
dnl
dnl Optional flags, check for compiler support
dnl
-AX_CHECK_COMPILE_FLAG([-msse4.1], [SSE41_SUPPORTED=1], [SSE41_SUPPORTED=0])
+save_CFLAGS=$CFLAGS
+CFLAGS=-msse4.1 $CFLAGS
+AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
+#include mmintrin.h
+#include xmmintrin.h
+#include emmintrin.h
+#include smmintrin.h
+int main () {
+__m128i a = _mm_set1_epi32 (0), b = _mm_set1_epi32 (0), c;
+c = _mm_max_epu32(a, b);
+return 0;
+}]])], SSE41_SUPPORTED=1)
+CFLAGS=$save_CFLAGS
if test x$SSE41_SUPPORTED = x1; then
DEFINES=$DEFINES -DUSE_SSE41
fi
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Bump version to 10.5.0-devel.
On Sat, Nov 15, 2014 at 3:20 AM, Emil Velikov emil.l.veli...@gmail.com wrote: Hi Vinson, I've deliberately omitted the version update, pending the conclusion of the Move mesa version scheme to a more common style ? thread Wouldn't the master branch be 10.5.0-devel regardless? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] configure.ac: roll up a program for the sse4.1 check
On 15/11/14 18:21, Matt Turner wrote:
On Sat, Nov 15, 2014 at 9:04 AM, Emil Velikov emil.l.veli...@gmail.com
wrote:
So when checking/building sse code we have three possibilities:
1 Old compiler, throws an error when using -msse*
2 New compiler, user disables sse* (-mno-sse*)
3 New compiler, user doesn't disable sse
The original code, added code for #1 but not #2. Later on we patched
around the lack of handling #2 by wrapping the code in __SSE4_1__.
Yet it lead to a missing/undefined symbol in case of #1 or #2, which
might cause an issue for #2 when using the i965 driver.
A bit later we fixed the undefined symbol by using #1, rather than
updating it to handle #2. With this commit we set things straight :)
To top it all up, conventions state that in case of conflicting
(-enable-foo -disable-foo) options, the latter one takes precedence.
Thus we need to make sure to prepend -msse4.1 to CFLAGS in our test.
Cc: Siavash Eliasi siavashser...@gmail.com
Cc: Matt Turner matts...@gmail.com
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
Man this thing is _very_ messy.
Matt from the last hunk it seems that pixman might need fixing. Should
be bother with that, or let people have fun when they hit it :P
I don't know what you mean, specifically.
configure.ac (in pixman) does:
CFLAGS=$CFLAGS -msse4.1
AC_COMPILE_IFELSE(...)
Which overwrites the cflags set by the user. I.e. it will not honour
-mno-sse4.1. At build time things will blow up, as CFLAGS, are placed
after AM_CFLAGS. I.e. in the makefiles the user knows best while in
configure it's the opposite.
-Emil
configure.ac | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 91e111b..9d1835e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -252,7 +252,19 @@ AC_SUBST([VISIBILITY_CXXFLAGS])
dnl
dnl Optional flags, check for compiler support
dnl
-AX_CHECK_COMPILE_FLAG([-msse4.1], [SSE41_SUPPORTED=1], [SSE41_SUPPORTED=0])
+save_CFLAGS=$CFLAGS
+CFLAGS=-msse4.1 $CFLAGS
+AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
+#include mmintrin.h
+#include xmmintrin.h
+#include emmintrin.h
+#include smmintrin.h
I think all you need to include is smmintrin.h.
True, blame pixman for the rest :P
-Emil
+int main () {
+__m128i a = _mm_set1_epi32 (0), b = _mm_set1_epi32 (0), c;
+c = _mm_max_epu32(a, b);
+return 0;
+}]])], SSE41_SUPPORTED=1)
+CFLAGS=$save_CFLAGS
if test x$SSE41_SUPPORTED = x1; then
DEFINES=$DEFINES -DUSE_SSE41
fi
--
2.1.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/mesa: add a fallback for clear_with_quad when no vs_layer
Not all drivers can set gl_Layer from VS. Add a fallback that passes the
instance id from VS to GS, and then uses the GS to set the layer.
Tested by adding
quad_buffers |= clear_buffers;
clear_buffers = 0;
to the st_Clear logic, and forcing set_vertex_shader_layered in all
cases. No piglit regressions (on piglits with 'clear' in the name).
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
Cc: 10.3 10.4 mesa-sta...@lists.freedesktop.org
---
No explicit piglit test hits this path without the above hacks, so it went
under the radar for a long time. I tested this on nvc0 with the above hacks,
and double-checked that without them, things still worked.
src/gallium/auxiliary/util/u_simple_shaders.c | 70 +++
src/gallium/auxiliary/util/u_simple_shaders.h | 6 +++
src/mesa/state_tracker/st_cb_clear.c | 25 --
src/mesa/state_tracker/st_context.h | 1 +
4 files changed, 97 insertions(+), 5 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_simple_shaders.c
b/src/gallium/auxiliary/util/u_simple_shaders.c
index adf4887..2cf528b 100644
--- a/src/gallium/auxiliary/util/u_simple_shaders.c
+++ b/src/gallium/auxiliary/util/u_simple_shaders.c
@@ -124,6 +124,76 @@ void *util_make_layered_clear_vertex_shader(struct
pipe_context *pipe)
return pipe-create_vs_state(pipe, state);
}
+/**
+ * Takes position and color, and outputs position, color, and instance id.
+ */
+void *util_make_layered_clear_helper_vertex_shader(struct pipe_context *pipe)
+{
+ static const char text[] =
+ VERT\n
+ DCL IN[0]\n
+ DCL IN[1]\n
+ DCL SV[0], INSTANCEID\n
+ DCL OUT[0], POSITION\n
+ DCL OUT[1], GENERIC[0]\n
+ DCL OUT[2], GENERIC[1]\n
+
+ MOV OUT[0], IN[0]\n
+ MOV OUT[1], IN[1]\n
+ MOV OUT[2].x, SV[0].\n
+ END\n;
+ struct tgsi_token tokens[1000];
+ struct pipe_shader_state state = {tokens};
+
+ if (!tgsi_text_translate(text, tokens, Elements(tokens))) {
+ assert(0);
+ return NULL;
+ }
+ return pipe-create_vs_state(pipe, state);
+}
+
+/**
+ * Takes position, color, and target layer, and emits vertices on that target
+ * layer, with the specified color.
+ */
+void *util_make_layered_clear_geometry_shader(struct pipe_context *pipe)
+{
+ static const char text[] =
+ GEOM\n
+ PROPERTY GS_INPUT_PRIMITIVE TRIANGLES\n
+ PROPERTY GS_OUTPUT_PRIMITIVE TRIANGLE_STRIP\n
+ PROPERTY GS_MAX_OUTPUT_VERTICES 3\n
+ PROPERTY GS_INVOCATIONS 1\n
+ DCL IN[][0], POSITION\n /* position */
+ DCL IN[][1], GENERIC[0]\n /* color */
+ DCL IN[][2], GENERIC[1]\n /* vs invocation */
+ DCL OUT[0], POSITION\n
+ DCL OUT[1], GENERIC[0]\n
+ DCL OUT[2], LAYER\n
+ IMM[0] INT32 {0, 0, 0, 0}\n
+
+ MOV OUT[0], IN[0][0]\n
+ MOV OUT[1], IN[0][1]\n
+ MOV OUT[2].x, IN[0][2].\n
+ EMIT IMM[0].\n
+ MOV OUT[0], IN[1][0]\n
+ MOV OUT[1], IN[1][1]\n
+ MOV OUT[2].x, IN[1][2].\n
+ EMIT IMM[0].\n
+ MOV OUT[0], IN[2][0]\n
+ MOV OUT[1], IN[2][1]\n
+ MOV OUT[2].x, IN[2][2].\n
+ EMIT IMM[0].\n
+ END\n;
+ struct tgsi_token tokens[1000];
+ struct pipe_shader_state state = {tokens};
+
+ if (!tgsi_text_translate(text, tokens, Elements(tokens))) {
+ assert(0);
+ return NULL;
+ }
+ return pipe-create_gs_state(pipe, state);
+}
/**
* Make simple fragment texture shader:
diff --git a/src/gallium/auxiliary/util/u_simple_shaders.h
b/src/gallium/auxiliary/util/u_simple_shaders.h
index c1d14aa..b467b9f5 100644
--- a/src/gallium/auxiliary/util/u_simple_shaders.h
+++ b/src/gallium/auxiliary/util/u_simple_shaders.h
@@ -60,6 +60,12 @@ extern void *
util_make_layered_clear_vertex_shader(struct pipe_context *pipe);
extern void *
+util_make_layered_clear_helper_vertex_shader(struct pipe_context *pipe);
+
+extern void *
+util_make_layered_clear_geometry_shader(struct pipe_context *pipe);
+
+extern void *
util_make_fragment_tex_shader_writemask(struct pipe_context *pipe,
unsigned tex_target,
unsigned interp_mode,
diff --git a/src/mesa/state_tracker/st_cb_clear.c
b/src/mesa/state_tracker/st_cb_clear.c
index 2c1414e..e778556 100644
--- a/src/mesa/state_tracker/st_cb_clear.c
+++ b/src/mesa/state_tracker/st_cb_clear.c
@@ -88,6 +88,14 @@ st_destroy_clear(struct st_context *st)
cso_delete_vertex_shader(st-cso_context, st-clear.vs);
st-clear.vs = NULL;
}
+ if (st-clear.vs_layered) {
+ cso_delete_vertex_shader(st-cso_context, st-clear.vs_layered);
+ st-clear.vs_layered = NULL;
+ }
+ if (st-clear.gs_layered) {
+ cso_delete_geometry_shader(st-cso_context, st-clear.gs_layered);
+ st-clear.gs_layered = NULL;
+ }
}
@@ -127,6 +135,7 @@ set_vertex_shader(struct st_context *st)
}
cso_set_vertex_shader_handle(st-cso_context, st-clear.vs);
+
[Mesa-dev] [PATCHv2] configure.ac: roll up a program for the sse4.1 check
So when checking/building sse code we have three possibilities:
1 Old compiler, throws an error when using -msse*
2 New compiler, user disables sse* (-mno-sse*)
3 New compiler, user doesn't disable sse
The original code, added code for #1 but not #2. Later on we patched
around the lack of handling #2 by wrapping the code in __SSE4_1__.
Yet it lead to a missing/undefined symbol in case of #1 or #2, which
might cause an issue for #2 when using the i965 driver.
A bit later we fixed the undefined symbol by using #1, rather than
updating it to handle #2. With this commit we set things straight :)
To top it all up, conventions state that in case of conflicting
(-enable-foo -disable-foo) options, the latter one takes precedence.
Thus we need to make sure to prepend -msse4.1 to CFLAGS in our test.
v2: Clean the #includes. Suggested by Ilia, Matt Siavash.
Cc: Siavash Eliasi siavashser...@gmail.com
Cc: Matt Turner matts...@gmail.com
Tested-by: David Heidelberg da...@ixit.cz
Tested-by: Siavash Eliasi siavashser...@gmail.com
Reviewed-by: Matt Turner matts...@gmail.com
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
configure.ac | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 91e111b..8aa070d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -252,7 +252,16 @@ AC_SUBST([VISIBILITY_CXXFLAGS])
dnl
dnl Optional flags, check for compiler support
dnl
-AX_CHECK_COMPILE_FLAG([-msse4.1], [SSE41_SUPPORTED=1], [SSE41_SUPPORTED=0])
+save_CFLAGS=$CFLAGS
+CFLAGS=-msse4.1 $CFLAGS
+AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
+#include smmintrin.h
+int main () {
+__m128i a = _mm_set1_epi32 (0), b = _mm_set1_epi32 (0), c;
+c = _mm_max_epu32(a, b);
+return 0;
+}]])], SSE41_SUPPORTED=1)
+CFLAGS=$save_CFLAGS
if test x$SSE41_SUPPORTED = x1; then
DEFINES=$DEFINES -DUSE_SSE41
fi
--
2.1.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] configure.ac: roll up a program for the sse4.1 check
On Sat, Nov 15, 2014 at 10:30 AM, Emil Velikov emil.l.veli...@gmail.com wrote: On 15/11/14 18:21, Matt Turner wrote: On Sat, Nov 15, 2014 at 9:04 AM, Emil Velikov emil.l.veli...@gmail.com wrote: Man this thing is _very_ messy. Matt from the last hunk it seems that pixman might need fixing. Should be bother with that, or let people have fun when they hit it :P I don't know what you mean, specifically. configure.ac (in pixman) does: CFLAGS=$CFLAGS -msse4.1 AC_COMPILE_IFELSE(...) Where? I see MMX_CFLAGS=-mmmx -Winline ... CFLAGS=$MMX_CFLAGS $CFLAGS SSE2_CFLAGS=-msse2 -Winline ... CFLAGS=$SSE2_CFLAGS $CFLAGS and SSSE3_CFLAGS=-mssse3 -Winline ... CFLAGS=$SSSE3_CFLAGS $CFLAGS which looks like it's doing the right thing. I tried building it with -mno-ssse3 and it correctly disabled the SSSE3 code. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCHv2] configure.ac: roll up a program for the sse4.1 check
On Sat, Nov 15, 2014 at 10:37 AM, Emil Velikov emil.l.veli...@gmail.com wrote: So when checking/building sse code we have three possibilities: 1 Old compiler, throws an error when using -msse* 2 New compiler, user disables sse* (-mno-sse*) 3 New compiler, user doesn't disable sse The original code, added code for #1 but not #2. Later on we patched around the lack of handling #2 by wrapping the code in __SSE4_1__. Yet it lead to a missing/undefined symbol in case of #1 or #2, which might cause an issue for #2 when using the i965 driver. A bit later we fixed the undefined symbol by using #1, rather than updating it to handle #2. With this commit we set things straight :) To top it all up, conventions state that in case of conflicting (-enable-foo -disable-foo) options, the latter one takes precedence. Thus we need to make sure to prepend -msse4.1 to CFLAGS in our test. v2: Clean the #includes. Suggested by Ilia, Matt Siavash. Cc: Siavash Eliasi siavashser...@gmail.com Cc: Matt Turner matts...@gmail.com Get rid of the Ccs if people have responded before you commit. :) Tested-by: David Heidelberg da...@ixit.cz Tested-by: Siavash Eliasi siavashser...@gmail.com Reviewed-by: Matt Turner matts...@gmail.com Signed-off-by: Emil Velikov emil.l.veli...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] configure.ac: roll up a program for the sse4.1 check
On Sat, Nov 15, 2014 at 1:25 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
On 15/11/14 18:18, Matt Turner wrote:
On Sat, Nov 15, 2014 at 10:13 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Sat, Nov 15, 2014 at 12:04 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
So when checking/building sse code we have three possibilities:
1 Old compiler, throws an error when using -msse*
2 New compiler, user disables sse* (-mno-sse*)
3 New compiler, user doesn't disable sse
The original code, added code for #1 but not #2. Later on we patched
around the lack of handling #2 by wrapping the code in __SSE4_1__.
Yet it lead to a missing/undefined symbol in case of #1 or #2, which
might cause an issue for #2 when using the i965 driver.
A bit later we fixed the undefined symbol by using #1, rather than
updating it to handle #2. With this commit we set things straight :)
To top it all up, conventions state that in case of conflicting
(-enable-foo -disable-foo) options, the latter one takes precedence.
Thus we need to make sure to prepend -msse4.1 to CFLAGS in our test.
Cc: Siavash Eliasi siavashser...@gmail.com
Cc: Matt Turner matts...@gmail.com
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
Man this thing is _very_ messy.
Matt from the last hunk it seems that pixman might need fixing. Should
be bother with that, or let people have fun when they hit it :P
-Emil
configure.ac | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 91e111b..9d1835e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -252,7 +252,19 @@ AC_SUBST([VISIBILITY_CXXFLAGS])
dnl
dnl Optional flags, check for compiler support
dnl
-AX_CHECK_COMPILE_FLAG([-msse4.1], [SSE41_SUPPORTED=1],
[SSE41_SUPPORTED=0])
+save_CFLAGS=$CFLAGS
+CFLAGS=-msse4.1 $CFLAGS
+AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
+#include mmintrin.h
+#include xmmintrin.h
+#include emmintrin.h
+#include smmintrin.h
+int main () {
+__m128i a = _mm_set1_epi32 (0), b = _mm_set1_epi32 (0), c;
+c = _mm_max_epu32(a, b);
+return 0;
This seems complicated.
Ilia, did you really mean complicated or you're having a thing for me :)
I like simplicity.
Excessive ? Perhaps, but as Matt mentioned, actually checking one of the
functions you're going to use does not hurt.
Indeed. Checking the functions seems like a not-unreasonable thing to
do. Perhaps I'm naive and like to think that if __SSE_4_1__ is
defined, then all's well :)
(a) Just #include immintrin.h
(b) Is any of this even necessary? how about
int main() { return !__SSE_4_1__; }
Checking that you can actually using the intrinsics seens like a good
plan. Pixman's configure.ac has been doing that for a long time. I'd
rather copy that. It's not like we'd save much by not doing it.
That's where I drew the inspiration.
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] configure.ac: roll up a program for the sse4.1 check
On 15/11/14 18:38, Matt Turner wrote: On Sat, Nov 15, 2014 at 10:30 AM, Emil Velikov emil.l.veli...@gmail.com wrote: On 15/11/14 18:21, Matt Turner wrote: On Sat, Nov 15, 2014 at 9:04 AM, Emil Velikov emil.l.veli...@gmail.com wrote: Man this thing is _very_ messy. Matt from the last hunk it seems that pixman might need fixing. Should be bother with that, or let people have fun when they hit it :P I don't know what you mean, specifically. configure.ac (in pixman) does: CFLAGS=$CFLAGS -msse4.1 AC_COMPILE_IFELSE(...) Where? I see ... Pardon for the noise it seems to be a PEBKAC on my end :) -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Bump version to 10.5.0-devel.
On 15/11/14 18:28, Matt Turner wrote: On Sat, Nov 15, 2014 at 3:20 AM, Emil Velikov emil.l.veli...@gmail.com wrote: Hi Vinson, I've deliberately omitted the version update, pending the conclusion of the Move mesa version scheme to a more common style ? thread Wouldn't the master branch be 10.5.0-devel regardless? Perhaps I was not clear enough, but the plan was to use the numbering scheme throughout. Yet it seems that things are going to stay as is - 2 negative and 2 neutral votes :) -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa/main: Fix tmp_row memory leak in texstore_rgba_integer.
---
src/mesa/main/texstore.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
index f913e42..f858cef 100644
--- a/src/mesa/main/texstore.c
+++ b/src/mesa/main/texstore.c
@@ -1667,8 +1667,10 @@ texstore_rgba_integer(TEXSTORE_PARAMS)
assert(is_array !normalized);
- if (!is_array)
+ if (!is_array) {
+ free(tmp_row);
return GL_FALSE;
+ }
invert_swizzle(dst2rgba, rgba2dst);
compute_component_mapping(GL_RGBA, baseInternalFormat, base2rgba);
--
2.1.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa/main: Fix tmp_row memory leak in texstore_rgba_integer.
Good catch!
Reviewed-by: Jason Ekstrand jason.ekstr...@intel.com
Can you push or do you need me to?
On Sat, Nov 15, 2014 at 11:02 AM, Siavash Eliasi siavashser...@gmail.com
wrote:
---
src/mesa/main/texstore.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
index f913e42..f858cef 100644
--- a/src/mesa/main/texstore.c
+++ b/src/mesa/main/texstore.c
@@ -1667,8 +1667,10 @@ texstore_rgba_integer(TEXSTORE_PARAMS)
assert(is_array !normalized);
- if (!is_array)
+ if (!is_array) {
+ free(tmp_row);
return GL_FALSE;
+ }
invert_swizzle(dst2rgba, rgba2dst);
compute_component_mapping(GL_RGBA, baseInternalFormat, base2rgba);
--
2.1.3
___
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/mesa: add a fallback for clear_with_quad when no vs_layer
On Sat, Nov 15, 2014 at 1:38 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
Not all drivers can set gl_Layer from VS. Add a fallback that passes the
instance id from VS to GS, and then uses the GS to set the layer.
Tested by adding
quad_buffers |= clear_buffers;
clear_buffers = 0;
to the st_Clear logic, and forcing set_vertex_shader_layered in all
cases. No piglit regressions (on piglits with 'clear' in the name).
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
Cc: 10.3 10.4 mesa-sta...@lists.freedesktop.org
---
No explicit piglit test hits this path without the above hacks, so it went
under the radar for a long time. I tested this on nvc0 with the above hacks,
and double-checked that without them, things still worked.
Fun fact -- llvmpipe also needs this.
src/gallium/auxiliary/util/u_simple_shaders.c | 70
+++
src/gallium/auxiliary/util/u_simple_shaders.h | 6 +++
src/mesa/state_tracker/st_cb_clear.c | 25 --
src/mesa/state_tracker/st_context.h | 1 +
4 files changed, 97 insertions(+), 5 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_simple_shaders.c
b/src/gallium/auxiliary/util/u_simple_shaders.c
index adf4887..2cf528b 100644
--- a/src/gallium/auxiliary/util/u_simple_shaders.c
+++ b/src/gallium/auxiliary/util/u_simple_shaders.c
@@ -124,6 +124,76 @@ void *util_make_layered_clear_vertex_shader(struct
pipe_context *pipe)
return pipe-create_vs_state(pipe, state);
}
+/**
+ * Takes position and color, and outputs position, color, and instance id.
+ */
+void *util_make_layered_clear_helper_vertex_shader(struct pipe_context *pipe)
+{
+ static const char text[] =
+ VERT\n
+ DCL IN[0]\n
+ DCL IN[1]\n
+ DCL SV[0], INSTANCEID\n
+ DCL OUT[0], POSITION\n
+ DCL OUT[1], GENERIC[0]\n
+ DCL OUT[2], GENERIC[1]\n
+
+ MOV OUT[0], IN[0]\n
+ MOV OUT[1], IN[1]\n
+ MOV OUT[2].x, SV[0].\n
+ END\n;
+ struct tgsi_token tokens[1000];
+ struct pipe_shader_state state = {tokens};
+
+ if (!tgsi_text_translate(text, tokens, Elements(tokens))) {
+ assert(0);
+ return NULL;
+ }
+ return pipe-create_vs_state(pipe, state);
+}
+
+/**
+ * Takes position, color, and target layer, and emits vertices on that target
+ * layer, with the specified color.
+ */
+void *util_make_layered_clear_geometry_shader(struct pipe_context *pipe)
+{
+ static const char text[] =
+ GEOM\n
+ PROPERTY GS_INPUT_PRIMITIVE TRIANGLES\n
+ PROPERTY GS_OUTPUT_PRIMITIVE TRIANGLE_STRIP\n
+ PROPERTY GS_MAX_OUTPUT_VERTICES 3\n
+ PROPERTY GS_INVOCATIONS 1\n
+ DCL IN[][0], POSITION\n /* position */
+ DCL IN[][1], GENERIC[0]\n /* color */
+ DCL IN[][2], GENERIC[1]\n /* vs invocation */
+ DCL OUT[0], POSITION\n
+ DCL OUT[1], GENERIC[0]\n
+ DCL OUT[2], LAYER\n
+ IMM[0] INT32 {0, 0, 0, 0}\n
+
+ MOV OUT[0], IN[0][0]\n
+ MOV OUT[1], IN[0][1]\n
+ MOV OUT[2].x, IN[0][2].\n
+ EMIT IMM[0].\n
+ MOV OUT[0], IN[1][0]\n
+ MOV OUT[1], IN[1][1]\n
+ MOV OUT[2].x, IN[1][2].\n
+ EMIT IMM[0].\n
+ MOV OUT[0], IN[2][0]\n
+ MOV OUT[1], IN[2][1]\n
+ MOV OUT[2].x, IN[2][2].\n
+ EMIT IMM[0].\n
+ END\n;
+ struct tgsi_token tokens[1000];
+ struct pipe_shader_state state = {tokens};
+
+ if (!tgsi_text_translate(text, tokens, Elements(tokens))) {
+ assert(0);
+ return NULL;
+ }
+ return pipe-create_gs_state(pipe, state);
+}
/**
* Make simple fragment texture shader:
diff --git a/src/gallium/auxiliary/util/u_simple_shaders.h
b/src/gallium/auxiliary/util/u_simple_shaders.h
index c1d14aa..b467b9f5 100644
--- a/src/gallium/auxiliary/util/u_simple_shaders.h
+++ b/src/gallium/auxiliary/util/u_simple_shaders.h
@@ -60,6 +60,12 @@ extern void *
util_make_layered_clear_vertex_shader(struct pipe_context *pipe);
extern void *
+util_make_layered_clear_helper_vertex_shader(struct pipe_context *pipe);
+
+extern void *
+util_make_layered_clear_geometry_shader(struct pipe_context *pipe);
+
+extern void *
util_make_fragment_tex_shader_writemask(struct pipe_context *pipe,
unsigned tex_target,
unsigned interp_mode,
diff --git a/src/mesa/state_tracker/st_cb_clear.c
b/src/mesa/state_tracker/st_cb_clear.c
index 2c1414e..e778556 100644
--- a/src/mesa/state_tracker/st_cb_clear.c
+++ b/src/mesa/state_tracker/st_cb_clear.c
@@ -88,6 +88,14 @@ st_destroy_clear(struct st_context *st)
cso_delete_vertex_shader(st-cso_context, st-clear.vs);
st-clear.vs = NULL;
}
+ if (st-clear.vs_layered) {
+ cso_delete_vertex_shader(st-cso_context, st-clear.vs_layered);
+ st-clear.vs_layered = NULL;
+ }
+ if (st-clear.gs_layered) {
+
Re: [Mesa-dev] [PATCH] st/mesa: add a fallback for clear_with_quad when no vs_layer
Reviewed-by: Marek Olšák marek.ol...@amd.com
Marek
On Sat, Nov 15, 2014 at 7:38 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
Not all drivers can set gl_Layer from VS. Add a fallback that passes the
instance id from VS to GS, and then uses the GS to set the layer.
Tested by adding
quad_buffers |= clear_buffers;
clear_buffers = 0;
to the st_Clear logic, and forcing set_vertex_shader_layered in all
cases. No piglit regressions (on piglits with 'clear' in the name).
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
Cc: 10.3 10.4 mesa-sta...@lists.freedesktop.org
---
No explicit piglit test hits this path without the above hacks, so it went
under the radar for a long time. I tested this on nvc0 with the above hacks,
and double-checked that without them, things still worked.
src/gallium/auxiliary/util/u_simple_shaders.c | 70
+++
src/gallium/auxiliary/util/u_simple_shaders.h | 6 +++
src/mesa/state_tracker/st_cb_clear.c | 25 --
src/mesa/state_tracker/st_context.h | 1 +
4 files changed, 97 insertions(+), 5 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_simple_shaders.c
b/src/gallium/auxiliary/util/u_simple_shaders.c
index adf4887..2cf528b 100644
--- a/src/gallium/auxiliary/util/u_simple_shaders.c
+++ b/src/gallium/auxiliary/util/u_simple_shaders.c
@@ -124,6 +124,76 @@ void *util_make_layered_clear_vertex_shader(struct
pipe_context *pipe)
return pipe-create_vs_state(pipe, state);
}
+/**
+ * Takes position and color, and outputs position, color, and instance id.
+ */
+void *util_make_layered_clear_helper_vertex_shader(struct pipe_context *pipe)
+{
+ static const char text[] =
+ VERT\n
+ DCL IN[0]\n
+ DCL IN[1]\n
+ DCL SV[0], INSTANCEID\n
+ DCL OUT[0], POSITION\n
+ DCL OUT[1], GENERIC[0]\n
+ DCL OUT[2], GENERIC[1]\n
+
+ MOV OUT[0], IN[0]\n
+ MOV OUT[1], IN[1]\n
+ MOV OUT[2].x, SV[0].\n
+ END\n;
+ struct tgsi_token tokens[1000];
+ struct pipe_shader_state state = {tokens};
+
+ if (!tgsi_text_translate(text, tokens, Elements(tokens))) {
+ assert(0);
+ return NULL;
+ }
+ return pipe-create_vs_state(pipe, state);
+}
+
+/**
+ * Takes position, color, and target layer, and emits vertices on that target
+ * layer, with the specified color.
+ */
+void *util_make_layered_clear_geometry_shader(struct pipe_context *pipe)
+{
+ static const char text[] =
+ GEOM\n
+ PROPERTY GS_INPUT_PRIMITIVE TRIANGLES\n
+ PROPERTY GS_OUTPUT_PRIMITIVE TRIANGLE_STRIP\n
+ PROPERTY GS_MAX_OUTPUT_VERTICES 3\n
+ PROPERTY GS_INVOCATIONS 1\n
+ DCL IN[][0], POSITION\n /* position */
+ DCL IN[][1], GENERIC[0]\n /* color */
+ DCL IN[][2], GENERIC[1]\n /* vs invocation */
+ DCL OUT[0], POSITION\n
+ DCL OUT[1], GENERIC[0]\n
+ DCL OUT[2], LAYER\n
+ IMM[0] INT32 {0, 0, 0, 0}\n
+
+ MOV OUT[0], IN[0][0]\n
+ MOV OUT[1], IN[0][1]\n
+ MOV OUT[2].x, IN[0][2].\n
+ EMIT IMM[0].\n
+ MOV OUT[0], IN[1][0]\n
+ MOV OUT[1], IN[1][1]\n
+ MOV OUT[2].x, IN[1][2].\n
+ EMIT IMM[0].\n
+ MOV OUT[0], IN[2][0]\n
+ MOV OUT[1], IN[2][1]\n
+ MOV OUT[2].x, IN[2][2].\n
+ EMIT IMM[0].\n
+ END\n;
+ struct tgsi_token tokens[1000];
+ struct pipe_shader_state state = {tokens};
+
+ if (!tgsi_text_translate(text, tokens, Elements(tokens))) {
+ assert(0);
+ return NULL;
+ }
+ return pipe-create_gs_state(pipe, state);
+}
/**
* Make simple fragment texture shader:
diff --git a/src/gallium/auxiliary/util/u_simple_shaders.h
b/src/gallium/auxiliary/util/u_simple_shaders.h
index c1d14aa..b467b9f5 100644
--- a/src/gallium/auxiliary/util/u_simple_shaders.h
+++ b/src/gallium/auxiliary/util/u_simple_shaders.h
@@ -60,6 +60,12 @@ extern void *
util_make_layered_clear_vertex_shader(struct pipe_context *pipe);
extern void *
+util_make_layered_clear_helper_vertex_shader(struct pipe_context *pipe);
+
+extern void *
+util_make_layered_clear_geometry_shader(struct pipe_context *pipe);
+
+extern void *
util_make_fragment_tex_shader_writemask(struct pipe_context *pipe,
unsigned tex_target,
unsigned interp_mode,
diff --git a/src/mesa/state_tracker/st_cb_clear.c
b/src/mesa/state_tracker/st_cb_clear.c
index 2c1414e..e778556 100644
--- a/src/mesa/state_tracker/st_cb_clear.c
+++ b/src/mesa/state_tracker/st_cb_clear.c
@@ -88,6 +88,14 @@ st_destroy_clear(struct st_context *st)
cso_delete_vertex_shader(st-cso_context, st-clear.vs);
st-clear.vs = NULL;
}
+ if (st-clear.vs_layered) {
+ cso_delete_vertex_shader(st-cso_context, st-clear.vs_layered);
+ st-clear.vs_layered = NULL;
+ }
+ if (st-clear.gs_layered) {
[Mesa-dev] EXT/ARB direct state access extensions
Hello all, I would like to ask what is the status of DSA (direct state access) extensions in mesa. If I understand correctly, there was a GSoC project by Dylan Noblesmith and there currently is a dsa branch in mesa repo, but it's not actively worked on at the moment. Is there any particular reason for not mainlining this other than there being not enough interest in it? Or was the code not ready for inclusion? Since the GL 4.5 includes the DSA extension, it would be nice to support it in mesa. It also provides an easier way to use OpenGL and could decrease API call count. Regards, Gustaw ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] scons: Require glproto = 1.4.13 for X11.
GLXBadProfileARB and X_GLXCreateContextAtrribsARB require glproto =
1.4.13. These symbols were added in commit
d5d41112cbccd9301500e8e023be77eb9cb622cd st/xlib: Generate errors as
specified.
Signed-off-by: Vinson Lee v...@freedesktop.org
Cc: 10.4 mesa-sta...@lists.freedesktop.org
---
scons/gallium.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scons/gallium.py b/scons/gallium.py
index e3786d2..4df6e1a 100755
--- a/scons/gallium.py
+++ b/scons/gallium.py
@@ -621,7 +621,7 @@ def generate(env):
env.Tool('custom')
createInstallMethods(env)
-env.PkgCheckModules('X11', ['x11', 'xext', 'xdamage', 'xfixes'])
+env.PkgCheckModules('X11', ['x11', 'xext', 'xdamage', 'xfixes', 'glproto
= 1.4.13'])
env.PkgCheckModules('XCB', ['x11-xcb', 'xcb-glx = 1.8.1', 'xcb-dri2 =
1.8'])
env.PkgCheckModules('XF86VIDMODE', ['xxf86vm'])
env.PkgCheckModules('DRM', ['libdrm = 2.4.38'])
--
1.9.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] scons: Require glproto = 1.4.13 for X11.
On Sat, Nov 15, 2014 at 2:16 PM, Vinson Lee v...@freedesktop.org wrote:
GLXBadProfileARB and X_GLXCreateContextAtrribsARB require glproto =
1.4.13. These symbols were added in commit
d5d41112cbccd9301500e8e023be77eb9cb622cd st/xlib: Generate errors as
specified.
Signed-off-by: Vinson Lee v...@freedesktop.org
Cc: 10.4 mesa-sta...@lists.freedesktop.org
---
scons/gallium.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scons/gallium.py b/scons/gallium.py
index e3786d2..4df6e1a 100755
--- a/scons/gallium.py
+++ b/scons/gallium.py
@@ -621,7 +621,7 @@ def generate(env):
env.Tool('custom')
createInstallMethods(env)
-env.PkgCheckModules('X11', ['x11', 'xext', 'xdamage', 'xfixes'])
+env.PkgCheckModules('X11', ['x11', 'xext', 'xdamage', 'xfixes', 'glproto
= 1.4.13'])
env.PkgCheckModules('XCB', ['x11-xcb', 'xcb-glx = 1.8.1', 'xcb-dri2 =
1.8'])
env.PkgCheckModules('XF86VIDMODE', ['xxf86vm'])
env.PkgCheckModules('DRM', ['libdrm = 2.4.38'])
--
1.9.2
The autotools build system has required 1.4.14 since 2011 -- see
commit 1e39fc784bc.
It's not clear to me why this difference wouldn't have shown up before.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 84124] Please revert 8449121971ce1db03fea19665d314e523fdc10dd
https://bugs.freedesktop.org/show_bug.cgi?id=84124 --- Comment #6 from almos aaalmo...@gmail.com --- I noticed that 10.4 has recently been branched, but the release notes doesn't mention this change yet. -- You are receiving this mail because: You are the QA Contact for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 86326] clEnqueueNDRangeKernel global_work_offset ignored
https://bugs.freedesktop.org/show_bug.cgi?id=86326 Bug ID: 86326 Summary: clEnqueueNDRangeKernel global_work_offset ignored Product: Mesa Version: 10.3 Hardware: x86 (IA32) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Other Assignee: mesa-dev@lists.freedesktop.org Reporter: luke-jr+freedesktopb...@utopios.org global_work_offset can be used to specify an array of work_dim unsigned values that describe the offset used to calculate the global ID of a work-item. If global_work_offset is NULL, the global IDs start at offset (0, 0, ... 0). From: https://www.khronos.org/registry/cl/sdk/1.1/docs/man/xhtml/clEnqueueNDRangeKernel.html However, Mesa passes this into clover/core/kernel.cpp kernel::launch, which then simply ignores it entirely. Note that OpenCL 1.0 required global_work_offset to be NULL, but Mesa claims OpenCL 1.1, and if it was only OpenCL 1.0 it would still need to fail if global_work_offset was non-NULL. As a result of this bug, software tries to use global_work_offset and ends up with kernels executing with the wrong values for get_global_id(0) -- 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 1/2] nv50, nvc0: actually check constbufs for invalidation
The number of vertex buffers has nothing to do with the number of bound
constbufs.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
Cc: 10.4 10.3 mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/nouveau/nv50/nv50_context.c | 5 +++--
src/gallium/drivers/nouveau/nvc0/nvc0_context.c | 4 +++-
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_context.c
b/src/gallium/drivers/nouveau/nv50/nv50_context.c
index 07f6378..5e907d7 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_context.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_context.c
@@ -214,8 +214,9 @@ nv50_invalidate_resource_storage(struct nouveau_context
*ctx,
if (res-bind PIPE_BIND_CONSTANT_BUFFER) {
for (s = 0; s 3; ++s) {
- assert(nv50-num_vtxbufs = NV50_MAX_PIPE_CONSTBUFS);
- for (i = 0; i nv50-num_vtxbufs; ++i) {
+ for (i = 0; i NV50_MAX_PIPE_CONSTBUFS; ++i) {
+ if (!(nv50-constbuf_valid[s] (1 i)))
+continue;
if (!nv50-constbuf[s][i].user
nv50-constbuf[s][i].u.buf == res) {
nv50-dirty |= NV50_NEW_CONSTBUF;
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_context.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_context.c
index b33a673..49a46ea 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_context.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_context.c
@@ -232,7 +232,9 @@ nvc0_invalidate_resource_storage(struct nouveau_context
*ctx,
if (res-bind PIPE_BIND_CONSTANT_BUFFER) {
for (s = 0; s 5; ++s) {
- for (i = 0; i nvc0-num_vtxbufs; ++i) {
+ for (i = 0; i NVC0_MAX_PIPE_CONSTBUFS; ++i) {
+ if (!(nvc0-constbuf_valid[s] (1 i)))
+continue;
if (!nvc0-constbuf[s][i].user
nvc0-constbuf[s][i].u.buf == res) {
nvc0-dirty |= NVC0_NEW_CONSTBUF;
--
2.0.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] nv50, nvc0: buffer resources can be bound as other things down the line
res-bind is not an indicator of how the resource is currently bound.
buffers can be rebound across different binding points without changing
underlying storage.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
Cc: 10.4 10.3 mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/nouveau/nv50/nv50_context.c | 14 +++---
src/gallium/drivers/nouveau/nvc0/nvc0_context.c | 14 +++---
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_context.c
b/src/gallium/drivers/nouveau/nv50/nv50_context.c
index 5e907d7..1a53579 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_context.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_context.c
@@ -180,7 +180,12 @@ nv50_invalidate_resource_storage(struct nouveau_context
*ctx,
}
}
- if (res-bind PIPE_BIND_VERTEX_BUFFER) {
+ if (res-bind (PIPE_BIND_VERTEX_BUFFER |
+PIPE_BIND_INDEX_BUFFER |
+PIPE_BIND_CONSTANT_BUFFER |
+PIPE_BIND_STREAM_OUTPUT |
+PIPE_BIND_SAMPLER_VIEW)) {
+
assert(nv50-num_vtxbufs = PIPE_MAX_ATTRIBS);
for (i = 0; i nv50-num_vtxbufs; ++i) {
if (nv50-vtxbuf[i].buffer == res) {
@@ -190,14 +195,11 @@ nv50_invalidate_resource_storage(struct nouveau_context
*ctx,
return ref;
}
}
- }
- if (res-bind PIPE_BIND_INDEX_BUFFER) {
+
if (nv50-idxbuf.buffer == res)
if (!--ref)
return ref;
- }
- if (res-bind PIPE_BIND_SAMPLER_VIEW) {
for (s = 0; s 3; ++s) {
assert(nv50-num_textures[s] = PIPE_MAX_SAMPLERS);
for (i = 0; i nv50-num_textures[s]; ++i) {
@@ -210,9 +212,7 @@ nv50_invalidate_resource_storage(struct nouveau_context
*ctx,
}
}
}
- }
- if (res-bind PIPE_BIND_CONSTANT_BUFFER) {
for (s = 0; s 3; ++s) {
for (i = 0; i NV50_MAX_PIPE_CONSTBUFS; ++i) {
if (!(nv50-constbuf_valid[s] (1 i)))
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_context.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_context.c
index 49a46ea..3992460 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_context.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_context.c
@@ -196,7 +196,12 @@ nvc0_invalidate_resource_storage(struct nouveau_context
*ctx,
}
}
- if (res-bind PIPE_BIND_VERTEX_BUFFER) {
+ if (res-bind (PIPE_BIND_VERTEX_BUFFER |
+PIPE_BIND_INDEX_BUFFER |
+PIPE_BIND_CONSTANT_BUFFER |
+PIPE_BIND_STREAM_OUTPUT |
+PIPE_BIND_COMMAND_ARGS_BUFFER |
+PIPE_BIND_SAMPLER_VIEW)) {
for (i = 0; i nvc0-num_vtxbufs; ++i) {
if (nvc0-vtxbuf[i].buffer == res) {
nvc0-dirty |= NVC0_NEW_ARRAYS;
@@ -205,17 +210,14 @@ nvc0_invalidate_resource_storage(struct nouveau_context
*ctx,
return ref;
}
}
- }
- if (res-bind PIPE_BIND_INDEX_BUFFER) {
+
if (nvc0-idxbuf.buffer == res) {
nvc0-dirty |= NVC0_NEW_IDXBUF;
nouveau_bufctx_reset(nvc0-bufctx_3d, NVC0_BIND_IDX);
if (!--ref)
return ref;
}
- }
- if (res-bind PIPE_BIND_SAMPLER_VIEW) {
for (s = 0; s 5; ++s) {
for (i = 0; i nvc0-num_textures[s]; ++i) {
if (nvc0-textures[s][i]
@@ -228,9 +230,7 @@ nvc0_invalidate_resource_storage(struct nouveau_context
*ctx,
}
}
}
- }
- if (res-bind PIPE_BIND_CONSTANT_BUFFER) {
for (s = 0; s 5; ++s) {
for (i = 0; i NVC0_MAX_PIPE_CONSTBUFS; ++i) {
if (!(nvc0-constbuf_valid[s] (1 i)))
--
2.0.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] dri/kms: Always zero out struct drm_mode_create_dumb
On 13/11/14 18:05, Thierry Reding wrote: From: Thierry Reding tred...@nvidia.com The DRM_IOCTL_MODE_CREATE_DUMB (and others) IOCTL isn't very rigorously specified, which has the effect that some kernel drivers do not consider the .pitch and .size fields of struct drm_mode_create_dumb outputs only. Instead they will use these as lower bounds and overwrite them only if the values that they compute are larger than what userspace provided. This works if and only if userspace initializes the fields explicitly to either 0 or some meaningful value. However, if userspace just leaves the values uninitialized and the struct drm_mode_create_dumb is allocated on the stack for example, the driver may try to overallocate buffers. Fortunately most userspace does zero out the structure before passing it to the IOCTL, but there are rare exceptions. Mesa is one of them. In an attempt to rectify this situation, kernel drivers are being updated to not use the .pitch and .size fields as inputs. However in order to fix the issue with older kernels, make sure that Mesa always zeros out the structure as well. Future IOCTLs should be more rigorously defined so that structures can be validated and IOCTLs rejected if output fields aren't set to zero. Thanks Thierry. I'm pretty sure the intent here was not to misuse the API, yet again zeroing the struct sounds like a good idea. I've added Daniel's r-b and pushed this to master. Do you think it's of any use if we push this for the stable branches ? I've not checked your drm changes, this I don't know if we actually check/validate pitch size. Is the ioctl going to carry on, throw a warning or just error out ? Cheers, Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 86330] lp_bld_debug.cpp:112: multiple definition of `raw_debug_ostream::write_impl(char const*, unsigned long)'
https://bugs.freedesktop.org/show_bug.cgi?id=86330 Bug ID: 86330 Summary: lp_bld_debug.cpp:112: multiple definition of `raw_debug_ostream::write_impl(char const*, unsigned long)' Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Keywords: regression Severity: blocker Priority: medium Component: Mesa core Assignee: mesa-dev@lists.freedesktop.org Reporter: v...@freedesktop.org CC: emil.l.veli...@gmail.com mesa: 45e2ba1b8c9aec47b089eed536d3d7c1fcfb9909 (master 10.4.0-devel) CXXLDgallium_drv_video.la ../../../../src/gallium/auxiliary/.libs/libgallium.a(lt1-lp_bld_debug.o): In function `raw_debug_ostream::write_impl(char const*, unsigned long)': src/gallium/auxiliary/gallivm/lp_bld_debug.cpp:112: multiple definition of `raw_debug_ostream::write_impl(char const*, unsigned long)' -- 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] gallium/include/pipe: Added interface for atomic counter buffers in pipe
---
src/gallium/include/pipe/p_context.h | 5 +
src/gallium/include/pipe/p_defines.h | 7 ++-
src/gallium/include/pipe/p_state.h | 10 ++
3 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/src/gallium/include/pipe/p_context.h
b/src/gallium/include/pipe/p_context.h
index af5674f..bf3be31 100644
--- a/src/gallium/include/pipe/p_context.h
+++ b/src/gallium/include/pipe/p_context.h
@@ -44,6 +44,7 @@ struct pipe_blit_info;
struct pipe_box;
struct pipe_clip_state;
struct pipe_constant_buffer;
+struct pipe_counter_buffer;
struct pipe_depth_stencil_alpha_state;
struct pipe_draw_info;
struct pipe_fence_handle;
@@ -201,6 +202,10 @@ struct pipe_context {
uint shader, uint index,
struct pipe_constant_buffer *buf );
+ void (*set_counter_buffer)( struct pipe_context *,
+ uint shader, uint index,
+ struct pipe_counter_buffer *buf );
+
void (*set_framebuffer_state)( struct pipe_context *,
const struct pipe_framebuffer_state * );
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index 8c4e415..717ab6a 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -341,6 +341,7 @@ enum pipe_flush_flags {
#define PIPE_BIND_VERTEX_BUFFER(1 4) /* set_vertex_buffers */
#define PIPE_BIND_INDEX_BUFFER (1 5) /* draw_elements */
#define PIPE_BIND_CONSTANT_BUFFER (1 6) /* set_constant_buffer */
+#define PIPE_BIND_COUNTER_BUFFER (1 7) /* set_counter_buffer */
#define PIPE_BIND_DISPLAY_TARGET (1 8) /* flush_front_buffer */
#define PIPE_BIND_TRANSFER_WRITE (1 9) /* transfer_map */
#define PIPE_BIND_TRANSFER_READ(1 10) /* transfer_map */
@@ -572,6 +573,8 @@ enum pipe_cap {
PIPE_CAP_MAX_VERTEX_ATTRIB_STRIDE = 109,
PIPE_CAP_SAMPLER_VIEW_TARGET = 110,
PIPE_CAP_CLIP_HALFZ = 111,
+ PIPE_CAP_USER_COUNTER_BUFFERS = 112,
+ PIPE_CAP_COUNTER_BUFFER_OFFSET_ALIGNMENT = 113,
};
#define PIPE_QUIRK_TEXTURE_BORDER_COLOR_SWIZZLE_NV50 (1 0)
@@ -631,7 +634,9 @@ enum pipe_shader_cap
PIPE_SHADER_CAP_PREFERRED_IR,
PIPE_SHADER_CAP_TGSI_SQRT_SUPPORTED,
PIPE_SHADER_CAP_MAX_SAMPLER_VIEWS,
- PIPE_SHADER_CAP_DOUBLES
+ PIPE_SHADER_CAP_DOUBLES,
+ PIPE_SHADER_CAP_MAX_COUNTER_BUFFER_SIZE,
+ PIPE_SHADER_CAP_MAX_COUNTER_BUFFERS
};
/**
diff --git a/src/gallium/include/pipe/p_state.h
b/src/gallium/include/pipe/p_state.h
index 43bc48b..49fae5d 100644
--- a/src/gallium/include/pipe/p_state.h
+++ b/src/gallium/include/pipe/p_state.h
@@ -57,6 +57,7 @@ extern C {
#define PIPE_MAX_CLIP_PLANES 8
#define PIPE_MAX_COLOR_BUFS8
#define PIPE_MAX_CONSTANT_BUFFERS 32
+#define PIPE_MAX_COUNTER_BUFFERS 32
#define PIPE_MAX_SAMPLERS 16
#define PIPE_MAX_SHADER_INPUTS32
#define PIPE_MAX_SHADER_OUTPUTS 48 /* 32 GENERICs + POS, PSIZE, FOG, etc. */
@@ -462,6 +463,15 @@ struct pipe_constant_buffer {
const void *user_buffer; /** pointer to a user buffer if buffer == NULL */
};
+/**
+ * A Counter buffer. A new buffer is set everytime a variable with
+ * atomic_uint is defined.
+ */
+struct pipe_counter_buffer{
+ struct pipe_resource *buffer; /** The actual buffer */
+ unsigned buffer_offset; /** The offset to start of data in buffer in bytes
*/
+ const void *user_buffer; /** The buffer which is created by the compiler */
+};
/**
* A stream output target. The structure specifies the range vertices can
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 86330] lp_bld_debug.cpp:112: multiple definition of `raw_debug_ostream::write_impl(char const*, unsigned long)'
https://bugs.freedesktop.org/show_bug.cgi?id=86330 Vinson Lee v...@freedesktop.org changed: What|Removed |Added Keywords||bisected --- Comment #1 from Vinson Lee v...@freedesktop.org --- Reproduction steps: $ ./autogen.sh --with-dri-drivers= --with-gallium-drivers=i915,swrast $ make d936ef3fb75f2333f795e004204b87760e564b3f is the first bad commit commit d936ef3fb75f2333f795e004204b87760e564b3f Author: Emil Velikov emil.l.veli...@gmail.com Date: Sun Nov 16 01:07:32 2014 + auxiliary: ship all files in the distribution tarball - Add all headers into Makefile.sources - Don't forget the target-helpers - Add the python scripts the formats table/list (csv) - Temporary add vl/vl_winsys_dri.c to EXTRA_DIST until we rework the way VL is build. - Add the following to EXTRA_DIST - they are included via the generated u_indices_gen.c thus we should not add them to *SOURCES. indices/u_indices.c indices/u_unfilled_indices.c XXX: Should we nuke gallivm/f.cpp ? It seems that no-one is using it. v2: Rebase Signed-off-by: Emil Velikov emil.l.veli...@gmail.com :04 04 8b3325431a190c91f53fda5cfab5f2926f11628a 941f13adad070b33931d14cc3668f21b61626688 Msrc bisect run success -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] tinderbox build regression
no idea but I'm picking Emil as the culprit! Dave. From: http://tinderbox.x.org/builds/2014-11-16-/logs/mesa-mesa/#build make[3]: Entering directory `/home/tinderbox/mesa/mesa/src/gallium/targets/xa' CC libxatracker_la-target.lo CXXLDlibxatracker.la ../../../../src/gallium/auxiliary/.libs/libgallium.a(lt1-lp_bld_debug.o): In function `raw_debug_ostream::write_impl(char const*, unsigned long)': /home/tinderbox/mesa/mesa/src/gallium/auxiliary/gallivm/lp_bld_debug.cpp:111: multiple definition of `raw_debug_ostream::write_impl(char const*, unsigned long)' ../../../../src/gallium/auxiliary/.libs/libgallium.a(lp_bld_debug.o):/home/tinderbox/mesa/mesa/src/gallium/auxiliary/gallivm/lp_bld_debug.cpp:111: first defined here ../../../../src/gallium/auxiliary/.libs/libgallium.a(lt1-lp_bld_debug.o): In function `lp_check_alignment': /home/tinderbox/mesa/mesa/src/gallium/auxiliary/gallivm/lp_bld_debug.cpp:89: multiple definition of `lp_check_alignment' ../../../../src/gallium/auxiliary/.libs/libgallium.a(lp_bld_debug.o):/home/tinderbox/mesa/mesa/src/gallium/auxiliary/gallivm/lp_bld_debug.cpp:89: first defined here ../../../../src/gallium/auxiliary/.libs/libgallium.a(lt1-lp_bld_debug.o): In function `lp_get_module_id': /home/tinderbox/mesa/mesa/src/gallium/auxiliary/gallivm/lp_bld_debug.cpp:126: multiple definition of `lp_get_module_id' ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] feature request for mesamatrix.net
I appreciate the work you've done to make the GL3.txt file much more readable. To improve it even more I would like to be able to click on the extensions names and see the whole text of the extension from the registry on opengl.org. I think it would help to understand why something isn't implemented yet and if it looks difficult, etc. Hi David! Thanks for the suggestion! I made the changes and am waiting for a code review from my other dev (https://github.com/MightyCreak/mesamatrix/compare/opengl-urls?expand=1). I preferred to make a direct link to the opengl.org specs, I think it's more mobile friendly than hover links. Cheers, Creak ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
