[Mesa-dev] [PATCH] scons: Define _DEFAULT_SOURCE.
Fix GCC cpp warnings with glibc >= 2.19. /usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp] # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" ^ Signed-off-by: Vinson Lee --- scons/gallium.py | 1 + 1 file changed, 1 insertion(+) diff --git a/scons/gallium.py b/scons/gallium.py index 5195508..2908257 100755 --- a/scons/gallium.py +++ b/scons/gallium.py @@ -283,6 +283,7 @@ def generate(env): '_SVID_SOURCE', '_BSD_SOURCE', '_GNU_SOURCE', +'_DEFAULT_SOURCE', 'HAVE_PTHREAD', 'HAVE_POSIX_MEMALIGN', ] -- 2.3.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] docs: describe the NVC0_COMPUTE envvar
Signed-off-by: Samuel Pitoiset --- docs/envvars.html | 4 1 file changed, 4 insertions(+) diff --git a/docs/envvars.html b/docs/envvars.html index 31d14a4..cb3eba0 100644 --- a/docs/envvars.html +++ b/docs/envvars.html @@ -227,6 +227,10 @@ for details. See the driver code for other, lesser-used variables. +Nouveau driver environment variables + +NVC0_COMPUTE - enable MP performance counters for nvc0+ + Other Gallium drivers have their own environment variables. These may change -- 2.3.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] configure.ac: Don't check for python mako module if python is not installed
On 28/02/15 20:42, Matt Turner wrote: > On Sat, Feb 28, 2015 at 3:10 AM, Emil Velikov > wrote: >> On 27/02/15 17:42, Matt Turner wrote: >>> For flex and bison, we check if a generated source file exists, which >>> is probably a good idea. That way configure will fail in a git >>> checkout if you don't have python. >>> >> Checking for the presence of one auto-generated file does not sound like >> a great idea imho. What happens if any of the other files is not present >> - should we keep the whole list in configure.ac ? Keeping the list in >> sync seems quite error prone. > > I copied the check-for-a-file pattern from libxkbcommon at the > recommendation of Gaetan Nadon more than three years ago, and as far > as I'm aware it's worked just fine. That's not to say that it's > perfect, but claiming something that's been working fine for three > years is "not a great idea" without offering a suggestion is a bit off > putting. > There was a suggestion below which admittedly is quite a ugly one. From a quick look at libxkbcommon, there has been a case where the file was renamed, and the hunk was not updated. That said I think that trying to keep the list in sync is perhaps the best thing we can do. The alternative solution from #autotools was to just warn when python/lex/etc. is missing and fail at build stage. > > Maybe I've misunderstood how this patch works. From the sound of > "without Python it is going to fail anyway because Python is not > present when trying to autogenerate the files" it seems that we're > okay with not checking for mako if Python isn't present because > running make is going to fail anyway? > > That doesn't sound like what we want -- it's configure's job to > determine if we have the necessary dependencies for make to succeed. > To sum it all up, how does this sound: * Change ax_check_python_mako_module.m4 to set a variable, rather than error out. This way we can have a bit more flexibility in configure.ac * python is not found and X is not generated - error(you need python for X) * python/mako is not found and Y is not generated - error(you need python/mako for Y). Keeping the checks and error messages for python and mako separate of course. > I'll think about this some more. > >> A hacky alternative is to set the variable (BISON/LEX/PYTHON2) to >> something like `echo "Missing XXX dependency" && return 1` when empty. >> Yet that looks quite nasty, plus it shows rather late in the build >> process :\ >> >>> I have in my todo list to add some remaining source files generated by >>> python to the autotools distribution. After we commit some version of >>> this patch, Emil or I should make sure that all the python-generated >>> code is included in the tarball. >>> >> I was under the impression that we already do, but I will double-check. >> >> >> On a mildly related note: >> For anyone that missed it Ken voiced concerns over shipping the >> lex/bison generated files. Main idea is that as(if) security bugs are >> found and fixed in those products, mesa has been released with such >> vulnerable files. >> I can see his point, and I tend to agree with him. How do others feel on >> the topic ? > > Someone concerned should talk to the automake/bison/flex upstreams and > see what they think. It is of course automake that adds the generated > code to the distribution. > > We're certainly not the only project shipping code generated by flex and > bison. > Ack. Just wanted to point out for anyone that was not in #dri-devel. Perhaps we can carry on in a separate thread if/when needed. -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/6] egl: Drop non-c99 keywords - INLINE, __FUNCTION__
On 28/02/15 18:00, Matt Turner wrote: > On Sat, Feb 28, 2015 at 9:48 AM, Emil Velikov > wrote: >> Here is to another round of cleanups :-) > > The series is > > Reviewed-by: Matt Turner > Thanks. I'll give it a couple of days for any comments/objections and push the lot. >> Namely we drop the use and definition of INLINE, __FUNCTION__ and use >> their c99 brothers. >> >> Patch 3 hides the internal _egl* symbols, which is no longer needed >> since we disabled st/egl. We might want to have this patch in 10.5 but >> I won't push on it. > > Let's put it in 10.5, since I think there's a good chance it'll fix > this bug [0], which manifests when applications linked against Mesa's > libEGL (with extra symbols) try to run against NVIDIA's libEGL. > > [0] https://bugs.gentoo.org/show_bug.cgi?id=501328 > Rafał Mużyło analysis seems to be on the spot. llvm-config --ldflags does produce some weird stuff, which we don't handle too well. Perhaps as we get into clearing up the llvm handling (or our configure.ac) we can double check. Until then this will do :-) Cheers Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] configure: simplify visibility compiler flag detection
This patch simplifies the visibility compiler flag detection in configure and
makes it more generic to also support compilers other than gcc.
Cc: Emil Velikov
Signed-off-by: Marc Dietrich
---
configure.ac | 32 +++-
1 file changed, 7 insertions(+), 25 deletions(-)
diff --git a/configure.ac b/configure.ac
index 5fbb7bc..7565c0c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -189,6 +189,7 @@ AX_GCC_FUNC_ATTRIBUTE([flatten])
AX_GCC_FUNC_ATTRIBUTE([format])
AX_GCC_FUNC_ATTRIBUTE([malloc])
AX_GCC_FUNC_ATTRIBUTE([packed])
+AX_GCC_FUNC_ATTRIBUTE([visibility])
AM_CONDITIONAL([GEN_ASM_OFFSETS], test "x$GEN_ASM_OFFSETS" = xyes)
@@ -223,6 +224,12 @@ cygwin*)
;;
esac
+# Enable -fvisibility=hidden if using a compiler that supports it
+if test "x${ax_cv_have_func_attribute_visibility}" = xyes; then
+ VISIBILITY_CFLAGS="-fvisibility=hidden"
+ VISIBILITY_CXXFLAGS="-fvisibility=hidden"
+fi
+
dnl Add flags for gcc and g++
if test "x$GCC" = xyes; then
CFLAGS="$CFLAGS -Wall"
@@ -245,18 +252,6 @@ if test "x$GCC" = xyes; then
AC_MSG_RESULT([yes]),
[CFLAGS="$save_CFLAGS -Wmissing-prototypes";
AC_MSG_RESULT([no])]);
-
-# Enable -fvisibility=hidden if using a gcc that supports it
-save_CFLAGS="$CFLAGS"
-AC_MSG_CHECKING([whether $CC supports -fvisibility=hidden])
-VISIBILITY_CFLAGS="-fvisibility=hidden"
-CFLAGS="$CFLAGS $VISIBILITY_CFLAGS"
-AC_LINK_IFELSE([AC_LANG_PROGRAM()], AC_MSG_RESULT([yes]),
- [VISIBILITY_CFLAGS=""; AC_MSG_RESULT([no])]);
-
-# Restore CFLAGS; VISIBILITY_CFLAGS are added to it where needed.
-CFLAGS=$save_CFLAGS
-
# Work around aliasing bugs - developers should comment this out
CFLAGS="$CFLAGS -fno-strict-aliasing"
@@ -267,19 +262,6 @@ fi
if test "x$GXX" = xyes; then
CXXFLAGS="$CXXFLAGS -Wall"
-# Enable -fvisibility=hidden if using a gcc that supports it
-save_CXXFLAGS="$CXXFLAGS"
-AC_MSG_CHECKING([whether $CXX supports -fvisibility=hidden])
-VISIBILITY_CXXFLAGS="-fvisibility=hidden"
-CXXFLAGS="$CXXFLAGS $VISIBILITY_CXXFLAGS"
-AC_LANG_PUSH([C++])
-AC_LINK_IFELSE([AC_LANG_PROGRAM()], AC_MSG_RESULT([yes]),
- [VISIBILITY_CXXFLAGS="" ; AC_MSG_RESULT([no])]);
-AC_LANG_POP([C++])
-
-# Restore CXXFLAGS; VISIBILITY_CXXFLAGS are added to it where needed.
-CXXFLAGS=$save_CXXFLAGS
-
# Work around aliasing bugs - developers should comment this out
CXXFLAGS="$CXXFLAGS -fno-strict-aliasing"
--
2.3.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] draw: fix division-by-zero for empty geometry shaders
From: Marek Olšák Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89372 --- src/gallium/auxiliary/draw/draw_pt_emit.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/src/gallium/auxiliary/draw/draw_pt_emit.c b/src/gallium/auxiliary/draw/draw_pt_emit.c index b215c5f..d1eafd8 100644 --- a/src/gallium/auxiliary/draw/draw_pt_emit.c +++ b/src/gallium/auxiliary/draw/draw_pt_emit.c @@ -113,8 +113,11 @@ draw_pt_emit_prepare(struct pt_emit *emit, emit->translate = translate_cache_find(emit->cache, &hw_key); } - *max_vertices = (draw->render->max_vertex_buffer_bytes / -(vinfo->size * 4)); + if (!vinfo->size) + *max_vertices = 0; + else + *max_vertices = (draw->render->max_vertex_buffer_bytes / + (vinfo->size * 4)); } -- 2.1.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure: simplify visibility compiler flag detection
On 01/03/15 14:09, Marc Dietrich wrote: > This patch simplifies the visibility compiler flag detection in configure and > makes it more generic to also support compilers other than gcc. > > Cc: Emil Velikov > Signed-off-by: Marc Dietrich > Reviewed-by: Emil Velikov Looks great thank you. I'm assuming that you're short on commit access so I'm push this around Wednesday, unless there are further comments. -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 77449] Tracker bug for all bugs related to Steam titles
https://bugs.freedesktop.org/show_bug.cgi?id=77449 Kai changed: What|Removed |Added Depends on||89377 -- 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] scons: Define _DEFAULT_SOURCE.
On 01/03/15 08:49, Vinson Lee wrote: > Fix GCC cpp warnings with glibc >= 2.19. > > /usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and > _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp] > # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" >^ > Any ideas if this has any side effects when building for non-linux platforms - freebsd/darwin ? It's nice to see that I wasn't the only person getting all this spam :-) -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] docs: describe the NVC0_COMPUTE envvar
Why wouldn't they always just be enabled :) Also, do you have to set it to get MP counters on kepler+? And why is it called "compute" if it enables performance counters... probably does more than that, no? On Sun, Mar 1, 2015 at 6:44 AM, Samuel Pitoiset wrote: > Signed-off-by: Samuel Pitoiset > --- > docs/envvars.html | 4 > 1 file changed, 4 insertions(+) > > diff --git a/docs/envvars.html b/docs/envvars.html > index 31d14a4..cb3eba0 100644 > --- a/docs/envvars.html > +++ b/docs/envvars.html > @@ -227,6 +227,10 @@ for details. > See the driver code for other, lesser-used variables. > > > +Nouveau driver environment variables > + > +NVC0_COMPUTE - enable MP performance counters for nvc0+ > + > > > Other Gallium drivers have their own environment variables. These may change > -- > 2.3.0 > > ___ > 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] configure: simplify visibility compiler flag detection
On Sun, Mar 1, 2015 at 6:09 AM, Marc Dietrich wrote:
> This patch simplifies the visibility compiler flag detection in configure and
> makes it more generic to also support compilers other than gcc.
This simplification relies on the assumption that compilers support
-fvisibility=... if and only if they support
attribute(visibility("...")).
I guess that might be the case, but the logic doesn't seem very sound.
Is the 'if test "x$GCC" = xyes; then' test actually rejecting clang?
It doesn't seem so, since above there's a 'if test "x$GCC" = xyes -a
"x$acv_mesa_CLANG" = xno; then'
So, I guess it looks to me like we already support visibility
detection for !gcc.
>
> Cc: Emil Velikov
> Signed-off-by: Marc Dietrich
>
> ---
> configure.ac | 32 +++-
> 1 file changed, 7 insertions(+), 25 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 5fbb7bc..7565c0c 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -189,6 +189,7 @@ AX_GCC_FUNC_ATTRIBUTE([flatten])
> AX_GCC_FUNC_ATTRIBUTE([format])
> AX_GCC_FUNC_ATTRIBUTE([malloc])
> AX_GCC_FUNC_ATTRIBUTE([packed])
> +AX_GCC_FUNC_ATTRIBUTE([visibility])
>
> AM_CONDITIONAL([GEN_ASM_OFFSETS], test "x$GEN_ASM_OFFSETS" = xyes)
>
> @@ -223,6 +224,12 @@ cygwin*)
> ;;
> esac
>
> +# Enable -fvisibility=hidden if using a compiler that supports it
> +if test "x${ax_cv_have_func_attribute_visibility}" = xyes; then
> + VISIBILITY_CFLAGS="-fvisibility=hidden"
> + VISIBILITY_CXXFLAGS="-fvisibility=hidden"
Indent these the same amount as elsewhere.
> +fi
> +
> dnl Add flags for gcc and g++
> if test "x$GCC" = xyes; then
> CFLAGS="$CFLAGS -Wall"
> @@ -245,18 +252,6 @@ if test "x$GCC" = xyes; then
>AC_MSG_RESULT([yes]),
>[CFLAGS="$save_CFLAGS -Wmissing-prototypes";
> AC_MSG_RESULT([no])]);
> -
> -# Enable -fvisibility=hidden if using a gcc that supports it
> -save_CFLAGS="$CFLAGS"
> -AC_MSG_CHECKING([whether $CC supports -fvisibility=hidden])
> -VISIBILITY_CFLAGS="-fvisibility=hidden"
> -CFLAGS="$CFLAGS $VISIBILITY_CFLAGS"
> -AC_LINK_IFELSE([AC_LANG_PROGRAM()], AC_MSG_RESULT([yes]),
> - [VISIBILITY_CFLAGS=""; AC_MSG_RESULT([no])]);
> -
> -# Restore CFLAGS; VISIBILITY_CFLAGS are added to it where needed.
> -CFLAGS=$save_CFLAGS
> -
> # Work around aliasing bugs - developers should comment this out
> CFLAGS="$CFLAGS -fno-strict-aliasing"
>
> @@ -267,19 +262,6 @@ fi
> if test "x$GXX" = xyes; then
> CXXFLAGS="$CXXFLAGS -Wall"
>
> -# Enable -fvisibility=hidden if using a gcc that supports it
> -save_CXXFLAGS="$CXXFLAGS"
> -AC_MSG_CHECKING([whether $CXX supports -fvisibility=hidden])
> -VISIBILITY_CXXFLAGS="-fvisibility=hidden"
> -CXXFLAGS="$CXXFLAGS $VISIBILITY_CXXFLAGS"
> -AC_LANG_PUSH([C++])
> -AC_LINK_IFELSE([AC_LANG_PROGRAM()], AC_MSG_RESULT([yes]),
> - [VISIBILITY_CXXFLAGS="" ; AC_MSG_RESULT([no])]);
> -AC_LANG_POP([C++])
> -
> -# Restore CXXFLAGS; VISIBILITY_CXXFLAGS are added to it where needed.
> -CXXFLAGS=$save_CXXFLAGS
> -
> # Work around aliasing bugs - developers should comment this out
> CXXFLAGS="$CXXFLAGS -fno-strict-aliasing"
>
> --
> 2.3.0
>
> ___
> 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] configure: simplify visibility compiler flag detection
On 01/03/15 18:30, Matt Turner wrote:
> On Sun, Mar 1, 2015 at 6:09 AM, Marc Dietrich wrote:
>> This patch simplifies the visibility compiler flag detection in configure and
>> makes it more generic to also support compilers other than gcc.
>
> This simplification relies on the assumption that compilers support
> -fvisibility=... if and only if they support
> attribute(visibility("...")).
>
Hmm you're correct. I've naively assumed they both go hand in hand.
> I guess that might be the case, but the logic doesn't seem very sound.
>
> Is the 'if test "x$GCC" = xyes; then' test actually rejecting clang?
> It doesn't seem so, since above there's a 'if test "x$GCC" = xyes -a
> "x$acv_mesa_CLANG" = xno; then'
>
> So, I guess it looks to me like we already support visibility
> detection for !gcc.
>
The HAVE_FUNC_ATTRIBUTE_VISIBILITY define should already be there,
regardless of the compiler. On the -fvisibility... side we handle it for
GCC and compatible (i.e. clang) compilers.
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure: simplify visibility compiler flag detection
Am Sonntag 01 März 2015, 10:30:08 schrieb Matt Turner:
> On Sun, Mar 1, 2015 at 6:09 AM, Marc Dietrich wrote:
> > This patch simplifies the visibility compiler flag detection in configure
> > and makes it more generic to also support compilers other than gcc.
>
> This simplification relies on the assumption that compilers support
> -fvisibility=... if and only if they support
> attribute(visibility("...")).
>
> I guess that might be the case, but the logic doesn't seem very sound.
I think it's ok, because attribute(visibilty) is a gcc extension. So if any
compiler supports this, it wants to be gcc compatible for some reason.
Therefore -IMHO- this implicitly implies -fvisibility.
> Is the 'if test "x$GCC" = xyes; then' test actually rejecting clang?
> It doesn't seem so, since above there's a 'if test "x$GCC" = xyes -a
> "x$acv_mesa_CLANG" = xno; then'
>
> So, I guess it looks to me like we already support visibility
> detection for !gcc.
clang reports itself as gcc 4.2.1 or so (clang -dumpversion). This is why
there is an extra test. I see no obvious reason to keep it inside the if block
because it should be generic (not gcc/clang specific).
Marc
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure: simplify visibility compiler flag detection
Am Sonntag 01 März 2015, 17:28:18 schrieb Sedat Dilek: > On Sun, Mar 1, 2015 at 3:09 PM, Marc Dietrich wrote: > > This patch simplifies the visibility compiler flag detection in configure > > and makes it more generic to also support compilers other than gcc. > > > > Cc: Emil Velikov > > Signed-off-by: Marc Dietrich > > [ CC Matt ] > > What happened to 2/2 (mapi tls part)? > Was 2/2 dropped by a patch of Matt Turner (commit > 76cd0f00f44c0935dc7d6a0e14e0515f08a8e1dc "mapi: Don't rely on GNU void > pointer arithmetic.")? > Please clarify! I'll post another patch later which tries to fix the clang build error. For now, this patch is standalone and should not be applied together with other patches I sent before. Marc signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] scons: Define _DEFAULT_SOURCE.
On Sun, Mar 1, 2015 at 8:52 AM, Emil Velikov wrote: > On 01/03/15 08:49, Vinson Lee wrote: >> Fix GCC cpp warnings with glibc >= 2.19. >> >> /usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and >> _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp] >> # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" >>^ >> > Any ideas if this has any side effects when building for non-linux > platforms - freebsd/darwin ? > It's nice to see that I wasn't the only person getting all this spam :-) > > -Emil > This patch does not affect the Mac OS X SCons build. The FreeBSD SCons build has not worked for years. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] c99_alloca.h: Include stdlib.h on all non-Windows.
Fix build on FreeBSD. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89364 Signed-off-by: Vinson Lee --- include/c99_alloca.h | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/include/c99_alloca.h b/include/c99_alloca.h index 7a81c50..575f719 100644 --- a/include/c99_alloca.h +++ b/include/c99_alloca.h @@ -35,13 +35,9 @@ # define alloca _alloca -#elif defined(__MINGW32__) - -# include - #else /* !defined(_MSC_VER) */ -# include +# include #endif /* !defined(_MSC_VER) */ -- 2.1.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] c99_alloca.h: Include stdlib.h on all non-Windows.
On 03/ 1/15 12:52 PM, Vinson Lee wrote: Fix build on FreeBSD. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89364 Signed-off-by: Vinson Lee --- include/c99_alloca.h | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/include/c99_alloca.h b/include/c99_alloca.h index 7a81c50..575f719 100644 --- a/include/c99_alloca.h +++ b/include/c99_alloca.h @@ -35,13 +35,9 @@ # define alloca _alloca -#elif defined(__MINGW32__) - -# include - #else /* !defined(_MSC_VER) */ -# include +# include #endif /* !defined(_MSC_VER) */ Solaris defines alloca() in , not -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure: simplify visibility compiler flag detection
On 03/ 1/15 10:57 AM, Emil Velikov wrote:
On 01/03/15 18:30, Matt Turner wrote:
On Sun, Mar 1, 2015 at 6:09 AM, Marc Dietrich wrote:
This patch simplifies the visibility compiler flag detection in configure and
makes it more generic to also support compilers other than gcc.
This simplification relies on the assumption that compilers support
-fvisibility=... if and only if they support
attribute(visibility("...")).
Hmm you're correct. I've naively assumed they both go hand in hand.
The latest Solaris Studio compilers support attribute(visibility), but
not -fvisibility. The absolute latest (12.4, released a few months back)
also support the clang has_attribute() extension for checking what's
supported (which is one of the reasons it's used in the X11/Xfuncproto.h
header in xproto 7.0.27 & later).
https://docs.oracle.com/cd/E37069_01/html/E37074/gjzke.html
https://docs.oracle.com/cd/E37069_01/html/E37074/gopqx.html
http://cgit.freedesktop.org/xorg/proto/x11proto/commit/?id=ffd4a13042d24cb5c913207585191801a9a1603e
--
-Alan Coopersmith- alan.coopersm...@oracle.com
Oracle Solaris Engineering - http://blogs.oracle.com/alanc
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] docs: describe the NVC0_COMPUTE envvar
On 03/01/2015 07:21 PM, Ilia Mirkin wrote: Why wouldn't they always just be enabled :) Also, do you have to set it to get MP counters on kepler+? And why is it called "compute" if it enables performance counters... probably does more than that, no? It is not enabled by default because compute support on Fermi has weird effects on 3D. And, I didn't find the time to investigate about this, that's why it is still a bit experimental. :) Actually, NVC0_COMPUTE allows compute support which is required for MP counters in order to polls them. However, we only have to set it for nvc0:nve4 chipsets, so the documentation of this envvar could be more accurate. Should I have to submit a v2 and improve the documentation by something like "NVC0_COMPUTE - enable compute support which is required for MP performance counters on nvc0:nve4" ? On Sun, Mar 1, 2015 at 6:44 AM, Samuel Pitoiset wrote: Signed-off-by: Samuel Pitoiset --- docs/envvars.html | 4 1 file changed, 4 insertions(+) diff --git a/docs/envvars.html b/docs/envvars.html index 31d14a4..cb3eba0 100644 --- a/docs/envvars.html +++ b/docs/envvars.html @@ -227,6 +227,10 @@ for details. See the driver code for other, lesser-used variables. +Nouveau driver environment variables + +NVC0_COMPUTE - enable MP performance counters for nvc0+ + Other Gallium drivers have their own environment variables. These may change -- 2.3.0 ___ 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] docs: describe the NVC0_COMPUTE envvar
On Sun, Mar 1, 2015 at 4:55 PM, Samuel Pitoiset wrote: > > On 03/01/2015 07:21 PM, Ilia Mirkin wrote: >> >> Why wouldn't they always just be enabled :) Also, do you have to set >> it to get MP counters on kepler+? And why is it called "compute" if it >> enables performance counters... probably does more than that, no? > > > It is not enabled by default because compute support on Fermi has weird > effects on 3D. And, I didn't find the time to investigate about this, that's > why it is still a bit experimental. :) > > Actually, NVC0_COMPUTE allows compute support which is required for MP > counters in order to polls them. However, we only have to set it for > nvc0:nve4 chipsets, so the documentation of this envvar could be more > accurate. > > Should I have to submit a v2 and improve the documentation by something like > "NVC0_COMPUTE - enable compute support which is required for MP performance > counters on nvc0:nve4" ? It's unclear to me that this option should be advertised at all. First off it has weird side-effects, and secondly none of the other nouveau env vars are listed there (NV50_PROG_DEBUG/NV50_PROG_OPTIMIZE). However if you feel strongly about it, how about "Enable compute support on Fermi chips. This is required for __ . However it has side-effects of __ ." Note that "MP performance counters" only makes sense to people who are already fully aware of the NVC0_COMPUTE env var, and if they weren't, the first place they'd look would be in the code and not that envvars page. -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure: simplify visibility compiler flag detection
On 01/03/15 21:05, Alan Coopersmith wrote:
> On 03/ 1/15 10:57 AM, Emil Velikov wrote:
>> On 01/03/15 18:30, Matt Turner wrote:
>>> On Sun, Mar 1, 2015 at 6:09 AM, Marc Dietrich wrote:
This patch simplifies the visibility compiler flag detection in
configure and
makes it more generic to also support compilers other than gcc.
>>>
>>> This simplification relies on the assumption that compilers support
>>> -fvisibility=... if and only if they support
>>> attribute(visibility("...")).
>>>
>> Hmm you're correct. I've naively assumed they both go hand in hand.
>
> The latest Solaris Studio compilers support attribute(visibility), but
> not -fvisibility. The absolute latest (12.4, released a few months back)
> also support the clang has_attribute() extension for checking what's
> supported (which is one of the reasons it's used in the X11/Xfuncproto.h
> header in xproto 7.0.27 & later).
>
Ouch... so I was quite naive indeed.
So here are some interesting bits:
- HAVE_FUNC_ATTRIBUTE_VISIBILITY is likely to be undefined (0) with
Solaris Studio compilers, as the m4 macro checks for
__attribute__((visibility("default")));
__attribute__((visibility("hidden")));
__attribute__((visibility("internal")));
__attribute__((visibility("protected")));
As the last one does not appear in the 12.4 C User's Guide (linked
below) the compiler will likely error/warn.
Perhaps we can nuke the latter two, as they are unused presently, and
add them back when needed ?
- Considering the lack of -fvisibility, what is the normal visibility
"level" - hidden or default ? If the latter this means that every
library/module built exports a ton of internal symbols.
- Using the __has_attribute macro looks great, although I would suspect
that it will take a while for GCC and others to adopt(?).
Thanks for the insightful input Alan.
-Emil
> https://docs.oracle.com/cd/E37069_01/html/E37074/gjzke.html
> https://docs.oracle.com/cd/E37069_01/html/E37074/gopqx.html
> http://cgit.freedesktop.org/xorg/proto/x11proto/commit/?id=ffd4a13042d24cb5c913207585191801a9a1603e
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] scons: Define _DEFAULT_SOURCE.
On 01/03/15 20:21, Vinson Lee wrote: > On Sun, Mar 1, 2015 at 8:52 AM, Emil Velikov wrote: >> On 01/03/15 08:49, Vinson Lee wrote: >>> Fix GCC cpp warnings with glibc >= 2.19. >>> >>> /usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and >>> _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp] >>> # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use >>> _DEFAULT_SOURCE" >>>^ >>> >> Any ideas if this has any side effects when building for non-linux >> platforms - freebsd/darwin ? >> It's nice to see that I wasn't the only person getting all this spam :-) >> >> -Emil >> > > This patch does not affect the Mac OS X SCons build. In that case feel free to add Acked-by: Emil Velikov Would nice to wait if Brian/Jose/others have any comments. > The FreeBSD SCons > build has not worked for years. > That's unfortunate. Just curious are there any plans/hopes to revive/fix it ? -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure: simplify visibility compiler flagdetection
Am Sonntag 01 März 2015, 13:05:52 schrieb Alan Coopersmith:
> On 03/ 1/15 10:57 AM, Emil Velikov wrote:
> > On 01/03/15 18:30, Matt Turner wrote:
> >> On Sun, Mar 1, 2015 at 6:09 AM, Marc Dietrich wrote:
> >>> This patch simplifies the visibility compiler flag detection in
> >>> configure and makes it more generic to also support compilers other
> >>> than gcc.
> >>
> >> This simplification relies on the assumption that compilers support
> >> -fvisibility=... if and only if they support
> >> attribute(visibility("...")).
> >
> > Hmm you're correct. I've naively assumed they both go hand in hand.
>
> The latest Solaris Studio compilers support attribute(visibility), but
> not -fvisibility. The absolute latest (12.4, released a few months back)
> also support the clang has_attribute() extension for checking what's
> supported (which is one of the reasons it's used in the X11/Xfuncproto.h
> header in xproto 7.0.27 & later).
>
> https://docs.oracle.com/cd/E37069_01/html/E37074/gjzke.html
> https://docs.oracle.com/cd/E37069_01/html/E37074/gopqx.html
> http://cgit.freedesktop.org/xorg/proto/x11proto/commit/?id=ffd4a13042d24cb5c
> 913207585191801a9a1603e
thanks for this information, Alan. Now for me it looks like that the original
code was probably not so bad as it checks for -fvisibility directly.
Marc
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89387] Double delete in lp_bld_misc.cpp
https://bugs.freedesktop.org/show_bug.cgi?id=89387 Bug ID: 89387 Summary: Double delete in lp_bld_misc.cpp Product: Mesa Version: 10.5 Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Mesa core Assignee: mesa-dev@lists.freedesktop.org Reporter: ch...@cvine.freeserve.co.uk QA Contact: mesa-dev@lists.freedesktop.org I have been asked in bug #86958 to open a separate bug about the resolution of the compilation error reported there, where mesa is compiled against llvm>=3.6. To fix that compilation error, at line 504 of file lp_bld_misc.cpp the ShaderMemoryManager* object MM is passed to a unique_ptr object, which takes ownership of MM. However, in the event of the call to EngineBuilder::create() at line 523 failing, at line 530 delete is called manually on MM, thus leading to a possible double delete (since the destructor of the unique_ptr object having ownership will also attempt to delete MM). This may beg the question of what EngineBuilder::setMCJITMemoryManager(ShaderMemoryManager*) does in llvm < 3.6. If that method also tries to delete its argument when finished with, you would get a double delete in the error case (ie where EngineBuilder::create() fails) for earlier versions of llvm also. However, whatever the answer to that, the fix for bug 86958 is on the fact of it wrong. -- You are receiving this mail because: You are the QA Contact for the bug. 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@lists.freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=86958 --- Comment #7 from Chris Vine --- I have posted bug #89387, entitled "Double delete in lp_bld_misc.cpp". -- 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] configure: simplify visibility compiler flag detection
On 1 March 2015 at 22:38, Sedat Dilek wrote:
> On Sun, Mar 1, 2015 at 11:31 PM, Emil Velikov
> wrote:
>> On 01/03/15 21:05, Alan Coopersmith wrote:
>>> On 03/ 1/15 10:57 AM, Emil Velikov wrote:
On 01/03/15 18:30, Matt Turner wrote:
> On Sun, Mar 1, 2015 at 6:09 AM, Marc Dietrich wrote:
>> This patch simplifies the visibility compiler flag detection in
>> configure and
>> makes it more generic to also support compilers other than gcc.
>
> This simplification relies on the assumption that compilers support
> -fvisibility=... if and only if they support
> attribute(visibility("...")).
>
Hmm you're correct. I've naively assumed they both go hand in hand.
>>>
>>> The latest Solaris Studio compilers support attribute(visibility), but
>>> not -fvisibility. The absolute latest (12.4, released a few months back)
>>> also support the clang has_attribute() extension for checking what's
>>> supported (which is one of the reasons it's used in the X11/Xfuncproto.h
>>> header in xproto 7.0.27 & later).
>>>
>> Ouch... so I was quite naive indeed.
>>
>> So here are some interesting bits:
>>
>> - HAVE_FUNC_ATTRIBUTE_VISIBILITY is likely to be undefined (0) with
>> Solaris Studio compilers, as the m4 macro checks for
>>
>> __attribute__((visibility("default")));
>> __attribute__((visibility("hidden")));
>> __attribute__((visibility("internal")));
>> __attribute__((visibility("protected")));
>>
>> As the last one does not appear in the 12.4 C User's Guide (linked
>> below) the compiler will likely error/warn.
>>
>> Perhaps we can nuke the latter two, as they are unused presently, and
>> add them back when needed ?
>>
>> - Considering the lack of -fvisibility, what is the normal visibility
>> "level" - hidden or default ? If the latter this means that every
>> library/module built exports a ton of internal symbols.
>>
>
> From [1] for gcc:
>
> "Despite the nomenclature, ‘default’ always means public; i.e.,
> available to be linked against from outside the shared object.
> ‘protected’ and ‘internal’ are pretty useless in real-world usage so
> the only other commonly used option is ‘hidden’. The default if
> -fvisibility isn't specified is ‘default’, i.e., make every symbol
> public—this causes the same behavior as previous versions of GCC. "
>
I was talking/asking about the Solaris Studio compilers.
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] draw: fix division-by-zero for empty geometry shaders
On 2 March 2015 at 01:23, Marek Olšák wrote: > From: Marek Olšák > Reviewed-by: Dave Airlie > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89372 > --- > src/gallium/auxiliary/draw/draw_pt_emit.c | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/src/gallium/auxiliary/draw/draw_pt_emit.c > b/src/gallium/auxiliary/draw/draw_pt_emit.c > index b215c5f..d1eafd8 100644 > --- a/src/gallium/auxiliary/draw/draw_pt_emit.c > +++ b/src/gallium/auxiliary/draw/draw_pt_emit.c > @@ -113,8 +113,11 @@ draw_pt_emit_prepare(struct pt_emit *emit, >emit->translate = translate_cache_find(emit->cache, &hw_key); > } > > - *max_vertices = (draw->render->max_vertex_buffer_bytes / > -(vinfo->size * 4)); > + if (!vinfo->size) > + *max_vertices = 0; > + else > + *max_vertices = (draw->render->max_vertex_buffer_bytes / > + (vinfo->size * 4)); > } > > > -- > 2.1.0 > > ___ > 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] [Mesa-stable] [PATCH] mesa: Correct backwards NULL check.
On 02/28/2015 11:34 AM, Emil Velikov wrote: > On 28/02/15 19:15, Matt Turner wrote: >> Cc: "10.4, 10.5" > I swear that was brought up already... It was, and I thought I fixed it. I must have had some sort of rebase fail or something. :( Ugh. > Seems that v2 of commit 4fd8b301237 was supposed to address it, but only > the commit message ended updated :-( > > Reviewed-by: Emil Velikov > > -Emil > ___ > mesa-stable mailing list > mesa-sta...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-stable ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/8] util: Change hash_table to use quadratic probing.
On Sat, Feb 28, 2015 at 1:53 PM, Thomas Helland wrote: > This should give better cache locality, less memory consumption, > less code, and should also be faster since we avoid a modulo operation. > > This is not the quadratic probing function you see most places. > They do not accumulate, so you try hash +1, +4, +9, etc. > My code accumulates; so it becomes hash +1, +5, +14, etc. > It felt more natural to do it like this. > > However, it causes an assertion failure. > The search function is apparently returning null when it shouldn't. > This does not get caught by make-check. > This gets fixed by the next patch. > --- > src/util/hash_table.c | 91 > --- > src/util/hash_table.h | 1 - > 2 files changed, 43 insertions(+), 49 deletions(-) > > diff --git a/src/util/hash_table.c b/src/util/hash_table.c > index 3247593..542f583 100644 > --- a/src/util/hash_table.c > +++ b/src/util/hash_table.c > @@ -33,7 +33,7 @@ > */ > > /** > - * Implements an open-addressing, linear-reprobing hash table. > + * Implements an open-addressing, quadratic probing hash table. > * > * For more information, see: > * > @@ -51,44 +51,44 @@ > static const uint32_t deleted_key_value; > > /** > - * From Knuth -- a good choice for hash/rehash values is p, p-2 where > - * p and p-2 are both prime. These tables are sized to have an extra 10% > - * free to avoid exponential performance degradation as the hash table fills > + * From Knuth -- a good choice for hash values is p, where is prime. > + * These tables are sized to have an extra 10% free to avoid > + * exponential performance degradation as the hash table fills "[...] where is prime"? Where what is prime? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure: simplify visibility compiler flag detection
On Sun, Mar 1, 2015 at 7:30 PM, Matt Turner wrote:
> On Sun, Mar 1, 2015 at 6:09 AM, Marc Dietrich wrote:
>> This patch simplifies the visibility compiler flag detection in configure and
>> makes it more generic to also support compilers other than gcc.
>
> This simplification relies on the assumption that compilers support
> -fvisibility=... if and only if they support
> attribute(visibility("...")).
>
> I guess that might be the case, but the logic doesn't seem very sound.
>
> Is the 'if test "x$GCC" = xyes; then' test actually rejecting clang?
> It doesn't seem so, since above there's a 'if test "x$GCC" = xyes -a
> "x$acv_mesa_CLANG" = xno; then'
>
> So, I guess it looks to me like we already support visibility
> detection for !gcc.
>
This simplified patch does not work as expected with 2/2 v3 (see [1]).
It breaks my build with mesa v10.4.5.
- Sedat -
[1] http://patchwork.freedesktop.org/patch/42679/
>>
>> Cc: Emil Velikov
>> Signed-off-by: Marc Dietrich
>>
>> ---
>> configure.ac | 32 +++-
>> 1 file changed, 7 insertions(+), 25 deletions(-)
>>
>> diff --git a/configure.ac b/configure.ac
>> index 5fbb7bc..7565c0c 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -189,6 +189,7 @@ AX_GCC_FUNC_ATTRIBUTE([flatten])
>> AX_GCC_FUNC_ATTRIBUTE([format])
>> AX_GCC_FUNC_ATTRIBUTE([malloc])
>> AX_GCC_FUNC_ATTRIBUTE([packed])
>> +AX_GCC_FUNC_ATTRIBUTE([visibility])
>>
>> AM_CONDITIONAL([GEN_ASM_OFFSETS], test "x$GEN_ASM_OFFSETS" = xyes)
>>
>> @@ -223,6 +224,12 @@ cygwin*)
>> ;;
>> esac
>>
>> +# Enable -fvisibility=hidden if using a compiler that supports it
>> +if test "x${ax_cv_have_func_attribute_visibility}" = xyes; then
>> + VISIBILITY_CFLAGS="-fvisibility=hidden"
>> + VISIBILITY_CXXFLAGS="-fvisibility=hidden"
>
> Indent these the same amount as elsewhere.
>
>> +fi
>> +
>> dnl Add flags for gcc and g++
>> if test "x$GCC" = xyes; then
>> CFLAGS="$CFLAGS -Wall"
>> @@ -245,18 +252,6 @@ if test "x$GCC" = xyes; then
>>AC_MSG_RESULT([yes]),
>>[CFLAGS="$save_CFLAGS -Wmissing-prototypes";
>> AC_MSG_RESULT([no])]);
>> -
>> -# Enable -fvisibility=hidden if using a gcc that supports it
>> -save_CFLAGS="$CFLAGS"
>> -AC_MSG_CHECKING([whether $CC supports -fvisibility=hidden])
>> -VISIBILITY_CFLAGS="-fvisibility=hidden"
>> -CFLAGS="$CFLAGS $VISIBILITY_CFLAGS"
>> -AC_LINK_IFELSE([AC_LANG_PROGRAM()], AC_MSG_RESULT([yes]),
>> - [VISIBILITY_CFLAGS=""; AC_MSG_RESULT([no])]);
>> -
>> -# Restore CFLAGS; VISIBILITY_CFLAGS are added to it where needed.
>> -CFLAGS=$save_CFLAGS
>> -
>> # Work around aliasing bugs - developers should comment this out
>> CFLAGS="$CFLAGS -fno-strict-aliasing"
>>
>> @@ -267,19 +262,6 @@ fi
>> if test "x$GXX" = xyes; then
>> CXXFLAGS="$CXXFLAGS -Wall"
>>
>> -# Enable -fvisibility=hidden if using a gcc that supports it
>> -save_CXXFLAGS="$CXXFLAGS"
>> -AC_MSG_CHECKING([whether $CXX supports -fvisibility=hidden])
>> -VISIBILITY_CXXFLAGS="-fvisibility=hidden"
>> -CXXFLAGS="$CXXFLAGS $VISIBILITY_CXXFLAGS"
>> -AC_LANG_PUSH([C++])
>> -AC_LINK_IFELSE([AC_LANG_PROGRAM()], AC_MSG_RESULT([yes]),
>> - [VISIBILITY_CXXFLAGS="" ; AC_MSG_RESULT([no])]);
>> -AC_LANG_POP([C++])
>> -
>> -# Restore CXXFLAGS; VISIBILITY_CXXFLAGS are added to it where needed.
>> -CXXFLAGS=$save_CXXFLAGS
>> -
>> # Work around aliasing bugs - developers should comment this out
>> CXXFLAGS="$CXXFLAGS -fno-strict-aliasing"
>>
>> --
>> 2.3.0
>>
>> ___
>> 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] configure: simplify visibility compiler flag detection
On Sun, Mar 1, 2015 at 11:31 PM, Emil Velikov wrote:
> On 01/03/15 21:05, Alan Coopersmith wrote:
>> On 03/ 1/15 10:57 AM, Emil Velikov wrote:
>>> On 01/03/15 18:30, Matt Turner wrote:
On Sun, Mar 1, 2015 at 6:09 AM, Marc Dietrich wrote:
> This patch simplifies the visibility compiler flag detection in
> configure and
> makes it more generic to also support compilers other than gcc.
This simplification relies on the assumption that compilers support
-fvisibility=... if and only if they support
attribute(visibility("...")).
>>> Hmm you're correct. I've naively assumed they both go hand in hand.
>>
>> The latest Solaris Studio compilers support attribute(visibility), but
>> not -fvisibility. The absolute latest (12.4, released a few months back)
>> also support the clang has_attribute() extension for checking what's
>> supported (which is one of the reasons it's used in the X11/Xfuncproto.h
>> header in xproto 7.0.27 & later).
>>
> Ouch... so I was quite naive indeed.
>
> So here are some interesting bits:
>
> - HAVE_FUNC_ATTRIBUTE_VISIBILITY is likely to be undefined (0) with
> Solaris Studio compilers, as the m4 macro checks for
>
> __attribute__((visibility("default")));
> __attribute__((visibility("hidden")));
> __attribute__((visibility("internal")));
> __attribute__((visibility("protected")));
>
> As the last one does not appear in the 12.4 C User's Guide (linked
> below) the compiler will likely error/warn.
>
> Perhaps we can nuke the latter two, as they are unused presently, and
> add them back when needed ?
>
> - Considering the lack of -fvisibility, what is the normal visibility
> "level" - hidden or default ? If the latter this means that every
> library/module built exports a ton of internal symbols.
>
From [1] for gcc:
"Despite the nomenclature, ‘default’ always means public; i.e.,
available to be linked against from outside the shared object.
‘protected’ and ‘internal’ are pretty useless in real-world usage so
the only other commonly used option is ‘hidden’. The default if
-fvisibility isn't specified is ‘default’, i.e., make every symbol
public—this causes the same behavior as previous versions of GCC. "
- Sedat -
[1] https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html ->
"-fvisibility=[default|internal|hidden|protected]"
> - Using the __has_attribute macro looks great, although I would suspect
> that it will take a while for GCC and others to adopt(?).
>
> Thanks for the insightful input Alan.
>
> -Emil
>
>> https://docs.oracle.com/cd/E37069_01/html/E37074/gjzke.html
>> https://docs.oracle.com/cd/E37069_01/html/E37074/gopqx.html
>> http://cgit.freedesktop.org/xorg/proto/x11proto/commit/?id=ffd4a13042d24cb5c913207585191801a9a1603e
>>
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure: simplify visibility compiler flag detection
On Sun, Mar 1, 2015 at 3:09 PM, Marc Dietrich wrote:
> This patch simplifies the visibility compiler flag detection in configure and
> makes it more generic to also support compilers other than gcc.
>
> Cc: Emil Velikov
> Signed-off-by: Marc Dietrich
>
[ CC Matt ]
What happened to 2/2 (mapi tls part)?
Was 2/2 dropped by a patch of Matt Turner (commit
76cd0f00f44c0935dc7d6a0e14e0515f08a8e1dc "mapi: Don't rely on GNU void
pointer arithmetic.")?
Please clarify!
- Sedat -
> ---
> configure.ac | 32 +++-
> 1 file changed, 7 insertions(+), 25 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 5fbb7bc..7565c0c 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -189,6 +189,7 @@ AX_GCC_FUNC_ATTRIBUTE([flatten])
> AX_GCC_FUNC_ATTRIBUTE([format])
> AX_GCC_FUNC_ATTRIBUTE([malloc])
> AX_GCC_FUNC_ATTRIBUTE([packed])
> +AX_GCC_FUNC_ATTRIBUTE([visibility])
>
> AM_CONDITIONAL([GEN_ASM_OFFSETS], test "x$GEN_ASM_OFFSETS" = xyes)
>
> @@ -223,6 +224,12 @@ cygwin*)
> ;;
> esac
>
> +# Enable -fvisibility=hidden if using a compiler that supports it
> +if test "x${ax_cv_have_func_attribute_visibility}" = xyes; then
> + VISIBILITY_CFLAGS="-fvisibility=hidden"
> + VISIBILITY_CXXFLAGS="-fvisibility=hidden"
> +fi
> +
> dnl Add flags for gcc and g++
> if test "x$GCC" = xyes; then
> CFLAGS="$CFLAGS -Wall"
> @@ -245,18 +252,6 @@ if test "x$GCC" = xyes; then
>AC_MSG_RESULT([yes]),
>[CFLAGS="$save_CFLAGS -Wmissing-prototypes";
> AC_MSG_RESULT([no])]);
> -
> -# Enable -fvisibility=hidden if using a gcc that supports it
> -save_CFLAGS="$CFLAGS"
> -AC_MSG_CHECKING([whether $CC supports -fvisibility=hidden])
> -VISIBILITY_CFLAGS="-fvisibility=hidden"
> -CFLAGS="$CFLAGS $VISIBILITY_CFLAGS"
> -AC_LINK_IFELSE([AC_LANG_PROGRAM()], AC_MSG_RESULT([yes]),
> - [VISIBILITY_CFLAGS=""; AC_MSG_RESULT([no])]);
> -
> -# Restore CFLAGS; VISIBILITY_CFLAGS are added to it where needed.
> -CFLAGS=$save_CFLAGS
> -
> # Work around aliasing bugs - developers should comment this out
> CFLAGS="$CFLAGS -fno-strict-aliasing"
>
> @@ -267,19 +262,6 @@ fi
> if test "x$GXX" = xyes; then
> CXXFLAGS="$CXXFLAGS -Wall"
>
> -# Enable -fvisibility=hidden if using a gcc that supports it
> -save_CXXFLAGS="$CXXFLAGS"
> -AC_MSG_CHECKING([whether $CXX supports -fvisibility=hidden])
> -VISIBILITY_CXXFLAGS="-fvisibility=hidden"
> -CXXFLAGS="$CXXFLAGS $VISIBILITY_CXXFLAGS"
> -AC_LANG_PUSH([C++])
> -AC_LINK_IFELSE([AC_LANG_PROGRAM()], AC_MSG_RESULT([yes]),
> - [VISIBILITY_CXXFLAGS="" ; AC_MSG_RESULT([no])]);
> -AC_LANG_POP([C++])
> -
> -# Restore CXXFLAGS; VISIBILITY_CXXFLAGS are added to it where needed.
> -CXXFLAGS=$save_CXXFLAGS
> -
> # Work around aliasing bugs - developers should comment this out
> CXXFLAGS="$CXXFLAGS -fno-strict-aliasing"
>
> --
> 2.3.0
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure: simplify visibility compiler flag detection
On Sun, Mar 1, 2015 at 5:45 PM, Emil Velikov wrote: > On 01/03/15 14:09, Marc Dietrich wrote: >> This patch simplifies the visibility compiler flag detection in configure and >> makes it more generic to also support compilers other than gcc. >> >> Cc: Emil Velikov >> Signed-off-by: Marc Dietrich >> > Reviewed-by: Emil Velikov > > Looks great thank you. I'm assuming that you're short on commit access > so I'm push this around Wednesday, unless there are further comments. > Where is the 2/2 of this patch? Alone it does not work with LLVM/Clang v3.6.0 with mesa v10.4.5. If there is an additional patch, please point me to it. $ grep -i visibility logs/build-and-install-log_mesa-10-4-5_gallivm-fixes_mapi-tls-fixes_visibility-compiler-flag-detection_enable-glx-tlsllvm-3-6-0.txt checking for __attribute__((visibility))... yes Otherwise, feel free to add my... Tested-by: Sedat Dilek - Sedat - ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/6] i965/fs: Silence unused parameter warning
Not sure why you Cc'd me, but whatever. Seems obvious enough.
Reviewed-by: Jason Ekstrand
On 02/27/2015 06:50 PM, Ian Romanick wrote:
From: Ian Romanick
Unused since b18fd23.
brw_fs.cpp:2878:44: warning: unused parameter 'dispatch_width'
[-Wunused-parameter]
clear_deps_for_inst_src(fs_inst *inst, int dispatch_width, bool *deps,
^
Signed-off-by: Ian Romanick
Cc: Jason Ekstrand
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 0354f56..126b7d0 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -2875,8 +2875,7 @@ fs_visitor::remove_duplicate_mrf_writes()
}
static void
-clear_deps_for_inst_src(fs_inst *inst, int dispatch_width, bool *deps,
-int first_grf, int grf_len)
+clear_deps_for_inst_src(fs_inst *inst, bool *deps, int first_grf, int grf_len)
{
/* Clear the flag for registers that actually got read (as expected). */
for (int i = 0; i < inst->sources; i++) {
@@ -2927,8 +2926,7 @@
fs_visitor::insert_gen4_pre_send_dependency_workarounds(bblock_t *block,
memset(needs_dep, false, sizeof(needs_dep));
memset(needs_dep, true, write_len);
- clear_deps_for_inst_src(inst, dispatch_width,
- needs_dep, first_write_grf, write_len);
+ clear_deps_for_inst_src(inst, needs_dep, first_write_grf, write_len);
/* Walk backwards looking for writes to registers we're writing which
* aren't read since being written. If we hit the start of the program,
@@ -2968,8 +2966,7 @@
fs_visitor::insert_gen4_pre_send_dependency_workarounds(bblock_t *block,
}
/* Clear the flag for registers that actually got read (as expected). */
- clear_deps_for_inst_src(scan_inst, dispatch_width,
- needs_dep, first_write_grf, write_len);
+ clear_deps_for_inst_src(scan_inst, needs_dep, first_write_grf,
write_len);
/* Continue the loop only if we haven't resolved all the dependencies */
int i;
@@ -3014,8 +3011,7 @@
fs_visitor::insert_gen4_post_send_dependency_workarounds(bblock_t *block, fs_ins
}
/* Clear the flag for registers that actually got read (as expected). */
- clear_deps_for_inst_src(scan_inst, dispatch_width,
- needs_dep, first_write_grf, write_len);
+ clear_deps_for_inst_src(scan_inst, needs_dep, first_write_grf,
write_len);
/* We insert our reads as late as possible since they're reading the
* result of a SEND, which has massive latency.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/5] st/mesa: add ATC support
Signed-off-by: Ilia Mirkin
---
src/mesa/state_tracker/st_extensions.c | 5 +
src/mesa/state_tracker/st_format.c | 14 ++
2 files changed, 19 insertions(+)
diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa/state_tracker/st_extensions.c
index ce29d07..354eb7e 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -560,6 +560,11 @@ void st_init_extensions(struct pipe_screen *screen,
{ PIPE_FORMAT_X24S8_UINT,
PIPE_FORMAT_S8X24_UINT },
GL_TRUE }, /* at least one format must be supported */
+
+ { { o(AMD_compressed_ATC_texture) },
+{ PIPE_FORMAT_ATC_RGB,
+ PIPE_FORMAT_ATC_RGBA_EXPLICIT,
+ PIPE_FORMAT_ATC_RGBA_INTERPOLATED } },
};
/* Required: vertex fetch support. */
diff --git a/src/mesa/state_tracker/st_format.c
b/src/mesa/state_tracker/st_format.c
index 7868bb5..58f4765 100644
--- a/src/mesa/state_tracker/st_format.c
+++ b/src/mesa/state_tracker/st_format.c
@@ -463,6 +463,13 @@ st_mesa_format_to_pipe_format(struct st_context *st,
mesa_format mesaFormat)
case MESA_FORMAT_ETC2_SRGB8_PUNCHTHROUGH_ALPHA1:
return st->has_etc2 ? PIPE_FORMAT_ETC2_SRGB8A1 :
PIPE_FORMAT_B8G8R8A8_SRGB;
+ case MESA_FORMAT_ATC_RGB:
+ return PIPE_FORMAT_ATC_RGB;
+ case MESA_FORMAT_ATC_RGBA_EXPLICIT:
+ return PIPE_FORMAT_ATC_RGBA_EXPLICIT;
+ case MESA_FORMAT_ATC_RGBA_INTERPOLATED:
+ return PIPE_FORMAT_ATC_RGBA_INTERPOLATED;
+
default:
return PIPE_FORMAT_NONE;
}
@@ -881,6 +888,13 @@ st_pipe_format_to_mesa_format(enum pipe_format format)
case PIPE_FORMAT_ETC2_RG11_SNORM:
return MESA_FORMAT_ETC2_SIGNED_RG11_EAC;
+ case PIPE_FORMAT_ATC_RGB:
+ return MESA_FORMAT_ATC_RGB;
+ case PIPE_FORMAT_ATC_RGBA_EXPLICIT:
+ return MESA_FORMAT_ATC_RGBA_EXPLICIT;
+ case PIPE_FORMAT_ATC_RGBA_INTERPOLATED:
+ return MESA_FORMAT_ATC_RGBA_INTERPOLATED;
+
default:
return MESA_FORMAT_NONE;
}
--
2.0.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/5] llvmpipe, softpipe: no support for ATC textures
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/llvmpipe/lp_screen.c | 3 ++-
src/gallium/drivers/softpipe/sp_screen.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c
b/src/gallium/drivers/llvmpipe/lp_screen.c
index 3387d3a..f6cb5fe 100644
--- a/src/gallium/drivers/llvmpipe/lp_screen.c
+++ b/src/gallium/drivers/llvmpipe/lp_screen.c
@@ -448,7 +448,8 @@ llvmpipe_is_format_supported( struct pipe_screen *_screen,
}
}
- if (format_desc->layout == UTIL_FORMAT_LAYOUT_BPTC) {
+ if (format_desc->layout == UTIL_FORMAT_LAYOUT_BPTC ||
+ format_desc->layout == UTIL_FORMAT_LAYOUT_ATC) {
/* Software decoding is not hooked up. */
return FALSE;
}
diff --git a/src/gallium/drivers/softpipe/sp_screen.c
b/src/gallium/drivers/softpipe/sp_screen.c
index a269328..ecf696e 100644
--- a/src/gallium/drivers/softpipe/sp_screen.c
+++ b/src/gallium/drivers/softpipe/sp_screen.c
@@ -348,7 +348,8 @@ softpipe_is_format_supported( struct pipe_screen *screen,
return FALSE;
}
- if (format_desc->layout == UTIL_FORMAT_LAYOUT_BPTC) {
+ if (format_desc->layout == UTIL_FORMAT_LAYOUT_BPTC ||
+ format_desc->layout == UTIL_FORMAT_LAYOUT_ATC) {
/* Software decoding is not hooked up. */
return FALSE;
}
--
2.0.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/5] freedreno/a3xx: add GL_AMD_compressed_ATC_texture support
Signed-off-by: Ilia Mirkin
---
docs/relnotes/10.6.0.html | 1 +
src/gallium/drivers/freedreno/a3xx/fd3_format.c | 4
2 files changed, 5 insertions(+)
diff --git a/docs/relnotes/10.6.0.html b/docs/relnotes/10.6.0.html
index d183c07..57fe4d5 100644
--- a/docs/relnotes/10.6.0.html
+++ b/docs/relnotes/10.6.0.html
@@ -44,6 +44,7 @@ Note: some of the new features are only available with
certain drivers.
+GL_AMD_compressed_ATC_texture on freedreno
GL_AMD_pinned_memory on r600, radeonsi
GL_ARB_draw_instanced on freedreno
GL_ARB_gpu_shader_fp64 on nvc0, softpipe
diff --git a/src/gallium/drivers/freedreno/a3xx/fd3_format.c
b/src/gallium/drivers/freedreno/a3xx/fd3_format.c
index 30b319b..cb243a7 100644
--- a/src/gallium/drivers/freedreno/a3xx/fd3_format.c
+++ b/src/gallium/drivers/freedreno/a3xx/fd3_format.c
@@ -268,6 +268,10 @@ static struct fd3_format formats[PIPE_FORMAT_COUNT] = {
_T(DXT3_SRGBA, DXT3, NONE, WZYX),
_T(DXT5_RGBA, DXT5, NONE, WZYX),
_T(DXT5_SRGBA, DXT5, NONE, WZYX),
+
+ _T(ATC_RGB, ATC_RGB, NONE, WZYX),
+ _T(ATC_RGBA_EXPLICIT, ATC_RGBA_EXPLICIT, NONE, WZYX),
+ _T(ATC_RGBA_INTERPOLATED, ATC_RGBA_INTERPOLATED, NONE, WZYX),
};
enum a3xx_vtx_fmt
--
2.0.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/5] mesa: add GL_AMD_compressed_ATC_texture support
Signed-off-by: Ilia Mirkin
---
src/mapi/glapi/gen/es_EXT.xml | 6 ++
src/mesa/main/extensions.c| 1 +
src/mesa/main/format_info.py | 2 ++
src/mesa/main/formats.c | 11 +++
src/mesa/main/formats.csv | 5 +
src/mesa/main/formats.h | 5 +
src/mesa/main/glformats.c | 8
src/mesa/main/glformats.h | 5 +
src/mesa/main/mtypes.h| 1 +
src/mesa/main/texcompress.c | 39 ++-
src/mesa/main/teximage.c | 15 +++
src/mesa/swrast/s_texfetch.c | 6 +-
12 files changed, 102 insertions(+), 2 deletions(-)
diff --git a/src/mapi/glapi/gen/es_EXT.xml b/src/mapi/glapi/gen/es_EXT.xml
index 3a2adeb..e691ae1 100644
--- a/src/mapi/glapi/gen/es_EXT.xml
+++ b/src/mapi/glapi/gen/es_EXT.xml
@@ -602,6 +602,12 @@
+
+
+
+
+
+
diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index f212015..913de1a 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@ -335,6 +335,7 @@ static const struct extension extension_table[] = {
/* Vendor extensions */
{ "GL_3DFX_texture_compression_FXT1",
o(TDFX_texture_compression_FXT1), GL, 1999 },
+ { "GL_AMD_compressed_ATC_texture",
o(AMD_compressed_ATC_texture), ES1 | ES2, 2007 },
{ "GL_AMD_conservative_depth", o(ARB_conservative_depth),
GL, 2009 },
{ "GL_AMD_draw_buffers_blend", o(ARB_draw_buffers_blend),
GL, 2009 },
{ "GL_AMD_performance_monitor", o(AMD_performance_monitor),
GL, 2007 },
diff --git a/src/mesa/main/format_info.py b/src/mesa/main/format_info.py
index 3bae57e..0c6fccf 100644
--- a/src/mesa/main/format_info.py
+++ b/src/mesa/main/format_info.py
@@ -130,6 +130,8 @@ def get_channel_bits(fmat, chan_name):
elif fmat.layout == 'bptc':
bits = 16 if fmat.name.endswith('_FLOAT') else 8
return bits if fmat.has_channel(chan_name) else 0
+ elif fmat.layout == 'atc':
+ return 8 if fmat.has_channel(chan_name) else 0
else:
assert False
else:
diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c
index df852f3..cf363b3 100644
--- a/src/mesa/main/formats.c
+++ b/src/mesa/main/formats.c
@@ -712,11 +712,14 @@ _mesa_get_uncompressed_format(mesa_format format)
case MESA_FORMAT_ETC1_RGB8:
case MESA_FORMAT_ETC2_RGB8:
case MESA_FORMAT_ETC2_SRGB8:
+ case MESA_FORMAT_ATC_RGB:
return MESA_FORMAT_BGR_UNORM8;
case MESA_FORMAT_ETC2_RGBA8_EAC:
case MESA_FORMAT_ETC2_SRGB8_ALPHA8_EAC:
case MESA_FORMAT_ETC2_RGB8_PUNCHTHROUGH_ALPHA1:
case MESA_FORMAT_ETC2_SRGB8_PUNCHTHROUGH_ALPHA1:
+ case MESA_FORMAT_ATC_RGBA_EXPLICIT:
+ case MESA_FORMAT_ATC_RGBA_INTERPOLATED:
return MESA_FORMAT_A8B8G8R8_UNORM;
case MESA_FORMAT_ETC2_R11_EAC:
case MESA_FORMAT_ETC2_SIGNED_R11_EAC:
@@ -1242,6 +1245,9 @@ _mesa_format_to_type_and_comps(mesa_format format,
case MESA_FORMAT_BPTC_SRGB_ALPHA_UNORM:
case MESA_FORMAT_BPTC_RGB_SIGNED_FLOAT:
case MESA_FORMAT_BPTC_RGB_UNSIGNED_FLOAT:
+ case MESA_FORMAT_ATC_RGB:
+ case MESA_FORMAT_ATC_RGBA_EXPLICIT:
+ case MESA_FORMAT_ATC_RGBA_INTERPOLATED:
/* XXX generate error instead? */
*datatype = GL_UNSIGNED_BYTE;
*comps = 0;
@@ -2079,6 +2085,11 @@ _mesa_format_matches_format_and_type(mesa_format
mesa_format,
case MESA_FORMAT_ETC2_SRGB8_PUNCHTHROUGH_ALPHA1:
return GL_FALSE;
+ case MESA_FORMAT_ATC_RGB:
+ case MESA_FORMAT_ATC_RGBA_EXPLICIT:
+ case MESA_FORMAT_ATC_RGBA_INTERPOLATED:
+ return GL_FALSE;
+
case MESA_FORMAT_A_SNORM8:
return format == GL_ALPHA && type == GL_BYTE;
case MESA_FORMAT_L_SNORM8:
diff --git a/src/mesa/main/formats.csv b/src/mesa/main/formats.csv
index e159e7d..1d669af 100644
--- a/src/mesa/main/formats.csv
+++ b/src/mesa/main/formats.csv
@@ -301,3 +301,8 @@ MESA_FORMAT_BPTC_RGBA_UNORM , bptc , 4, 4,
x128, , ,
MESA_FORMAT_BPTC_SRGB_ALPHA_UNORM , bptc , 4, 4, x128, , ,
, xyzw, srgb
MESA_FORMAT_BPTC_RGB_SIGNED_FLOAT , bptc , 4, 4, x128, , ,
, xyz1, rgb
MESA_FORMAT_BPTC_RGB_UNSIGNED_FLOAT , bptc , 4, 4, x128, , ,
, xyz1, rgb
+
+# ATC compressed formats
+MESA_FORMAT_ATC_RGB , atc , 4, 4, x64 , , ,
, xyz1, rgb
+MESA_FORMAT_ATC_RGBA_EXPLICIT , atc , 4, 4, x128, , ,
, xyzw, rgb
+MESA_FORMAT_ATC_RGBA_INTERPOLATED , atc , 4, 4, x128, , ,
, xyzw, rgb
diff --git a/src/mesa/main/formats.h b/src/mesa/main/formats.h
index 7e451ca..4909cad 100644
--- a/src/mesa/main/formats.h
+++ b/src/mesa/main/formats.h
@@ -575,6 +575,11 @@ typedef enum
MESA_FORMAT_BPTC_RGB_SIGNED_FLOAT,
MESA_FORMAT_BPTC_RGB_UNSIGNED_FLOA
[Mesa-dev] [PATCH 2/5] gallium: add ATC format support
Signed-off-by: Ilia Mirkin
---
src/gallium/auxiliary/util/u_format.csv | 4
src/gallium/auxiliary/util/u_format.h | 8 +++-
src/gallium/auxiliary/util/u_format_fake.c | 4
src/gallium/auxiliary/util/u_format_fake.h | 4
src/gallium/auxiliary/util/u_format_pack.py | 2 +-
src/gallium/include/pipe/p_format.h | 4
6 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_format.csv
b/src/gallium/auxiliary/util/u_format.csv
index d3b77e6..aae7200 100644
--- a/src/gallium/auxiliary/util/u_format.csv
+++ b/src/gallium/auxiliary/util/u_format.csv
@@ -202,6 +202,10 @@ PIPE_FORMAT_BPTC_SRGBA, bptc, 4, 4, x128,
, , , xyzw, sr
PIPE_FORMAT_BPTC_RGB_FLOAT, bptc, 4, 4, x128, , , , xyz1,
rgb
PIPE_FORMAT_BPTC_RGB_UFLOAT , bptc, 4, 4, x128, , , , xyz1,
rgb
+PIPE_FORMAT_ATC_RGB , atc, 4, 4, x64, , , , xyz1,
rgb
+PIPE_FORMAT_ATC_RGBA_EXPLICIT , atc, 4, 4, x128, , , , xyzw,
rgb
+PIPE_FORMAT_ATC_RGBA_INTERPOLATED , atc, 4, 4, x128, , , , xyzw,
rgb
+
# Straightforward D3D10-like formats (also used for
# vertex buffer element description)
#
diff --git a/src/gallium/auxiliary/util/u_format.h
b/src/gallium/auxiliary/util/u_format.h
index 621574c..0645870 100644
--- a/src/gallium/auxiliary/util/u_format.h
+++ b/src/gallium/auxiliary/util/u_format.h
@@ -84,9 +84,14 @@ enum util_format_layout {
UTIL_FORMAT_LAYOUT_BPTC = 7,
/**
+* ATI Texture Compression
+*/
+ UTIL_FORMAT_LAYOUT_ATC = 8,
+
+ /**
* Everything else that doesn't fit in any of the above layouts.
*/
- UTIL_FORMAT_LAYOUT_OTHER = 8
+ UTIL_FORMAT_LAYOUT_OTHER = 9
};
@@ -481,6 +486,7 @@ util_format_is_compressed(enum pipe_format format)
case UTIL_FORMAT_LAYOUT_RGTC:
case UTIL_FORMAT_LAYOUT_ETC:
case UTIL_FORMAT_LAYOUT_BPTC:
+ case UTIL_FORMAT_LAYOUT_ATC:
/* XXX add other formats in the future */
return TRUE;
default:
diff --git a/src/gallium/auxiliary/util/u_format_fake.c
b/src/gallium/auxiliary/util/u_format_fake.c
index 77e896d..0c9aeb6 100644
--- a/src/gallium/auxiliary/util/u_format_fake.c
+++ b/src/gallium/auxiliary/util/u_format_fake.c
@@ -35,3 +35,7 @@ fake(etc2_r11_unorm)
fake(etc2_r11_snorm)
fake(etc2_rg11_unorm)
fake(etc2_rg11_snorm)
+
+fake(atc_rgb)
+fake(atc_rgba_explicit)
+fake(atc_rgba_interpolated)
diff --git a/src/gallium/auxiliary/util/u_format_fake.h
b/src/gallium/auxiliary/util/u_format_fake.h
index e6bfd4e..ac816db 100644
--- a/src/gallium/auxiliary/util/u_format_fake.h
+++ b/src/gallium/auxiliary/util/u_format_fake.h
@@ -63,4 +63,8 @@ __format_fake(etc2_r11_snorm)
__format_fake(etc2_rg11_unorm)
__format_fake(etc2_rg11_snorm)
+__format_fake(atc_rgb)
+__format_fake(atc_rgba_explicit)
+__format_fake(atc_rgba_interpolated)
+
#endif
diff --git a/src/gallium/auxiliary/util/u_format_pack.py
b/src/gallium/auxiliary/util/u_format_pack.py
index d5138cc..eaa010b 100644
--- a/src/gallium/auxiliary/util/u_format_pack.py
+++ b/src/gallium/auxiliary/util/u_format_pack.py
@@ -686,7 +686,7 @@ def generate_format_fetch(format, dst_channel,
dst_native_type, dst_suffix):
def is_format_hand_written(format):
-return format.layout in ('s3tc', 'rgtc', 'etc', 'bptc', 'subsampled',
'other') or format.colorspace == ZS
+return format.layout in ('s3tc', 'rgtc', 'etc', 'bptc', 'atc',
'subsampled', 'other') or format.colorspace == ZS
def generate(formats):
diff --git a/src/gallium/include/pipe/p_format.h
b/src/gallium/include/pipe/p_format.h
index b2646d4..bcfebd4 100644
--- a/src/gallium/include/pipe/p_format.h
+++ b/src/gallium/include/pipe/p_format.h
@@ -359,6 +359,10 @@ enum pipe_format {
PIPE_FORMAT_ETC2_RG11_UNORM = 277,
PIPE_FORMAT_ETC2_RG11_SNORM = 278,
+ PIPE_FORMAT_ATC_RGB = 279,
+ PIPE_FORMAT_ATC_RGBA_EXPLICIT = 280,
+ PIPE_FORMAT_ATC_RGBA_INTERPOLATED = 281,
+
PIPE_FORMAT_COUNT
};
--
2.0.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/5] mesa: add GL_AMD_compressed_ATC_texture support
I don't know if you got everything but I didn't notice anything missing and
what's there looks correct to me.
Reviewed-by: Jason Ekstrand
On Mar 1, 2015 7:08 PM, "Ilia Mirkin" wrote:
> Signed-off-by: Ilia Mirkin
> ---
> src/mapi/glapi/gen/es_EXT.xml | 6 ++
> src/mesa/main/extensions.c| 1 +
> src/mesa/main/format_info.py | 2 ++
> src/mesa/main/formats.c | 11 +++
> src/mesa/main/formats.csv | 5 +
> src/mesa/main/formats.h | 5 +
> src/mesa/main/glformats.c | 8
> src/mesa/main/glformats.h | 5 +
> src/mesa/main/mtypes.h| 1 +
> src/mesa/main/texcompress.c | 39 ++-
> src/mesa/main/teximage.c | 15 +++
> src/mesa/swrast/s_texfetch.c | 6 +-
> 12 files changed, 102 insertions(+), 2 deletions(-)
>
> diff --git a/src/mapi/glapi/gen/es_EXT.xml b/src/mapi/glapi/gen/es_EXT.xml
> index 3a2adeb..e691ae1 100644
> --- a/src/mapi/glapi/gen/es_EXT.xml
> +++ b/src/mapi/glapi/gen/es_EXT.xml
> @@ -602,6 +602,12 @@
>
>
>
> +
> +
> +
> +
> +
> +
>
>
>
> diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
> index f212015..913de1a 100644
> --- a/src/mesa/main/extensions.c
> +++ b/src/mesa/main/extensions.c
> @@ -335,6 +335,7 @@ static const struct extension extension_table[] = {
>
> /* Vendor extensions */
> { "GL_3DFX_texture_compression_FXT1",
> o(TDFX_texture_compression_FXT1), GL, 1999 },
> + { "GL_AMD_compressed_ATC_texture",
> o(AMD_compressed_ATC_texture), ES1 | ES2, 2007 },
> { "GL_AMD_conservative_depth",
> o(ARB_conservative_depth), GL, 2009 },
> { "GL_AMD_draw_buffers_blend",
> o(ARB_draw_buffers_blend), GL, 2009 },
> { "GL_AMD_performance_monitor",
> o(AMD_performance_monitor), GL, 2007 },
> diff --git a/src/mesa/main/format_info.py b/src/mesa/main/format_info.py
> index 3bae57e..0c6fccf 100644
> --- a/src/mesa/main/format_info.py
> +++ b/src/mesa/main/format_info.py
> @@ -130,6 +130,8 @@ def get_channel_bits(fmat, chan_name):
>elif fmat.layout == 'bptc':
> bits = 16 if fmat.name.endswith('_FLOAT') else 8
> return bits if fmat.has_channel(chan_name) else 0
> + elif fmat.layout == 'atc':
> + return 8 if fmat.has_channel(chan_name) else 0
>else:
> assert False
> else:
> diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c
> index df852f3..cf363b3 100644
> --- a/src/mesa/main/formats.c
> +++ b/src/mesa/main/formats.c
> @@ -712,11 +712,14 @@ _mesa_get_uncompressed_format(mesa_format format)
> case MESA_FORMAT_ETC1_RGB8:
> case MESA_FORMAT_ETC2_RGB8:
> case MESA_FORMAT_ETC2_SRGB8:
> + case MESA_FORMAT_ATC_RGB:
>return MESA_FORMAT_BGR_UNORM8;
> case MESA_FORMAT_ETC2_RGBA8_EAC:
> case MESA_FORMAT_ETC2_SRGB8_ALPHA8_EAC:
> case MESA_FORMAT_ETC2_RGB8_PUNCHTHROUGH_ALPHA1:
> case MESA_FORMAT_ETC2_SRGB8_PUNCHTHROUGH_ALPHA1:
> + case MESA_FORMAT_ATC_RGBA_EXPLICIT:
> + case MESA_FORMAT_ATC_RGBA_INTERPOLATED:
>return MESA_FORMAT_A8B8G8R8_UNORM;
> case MESA_FORMAT_ETC2_R11_EAC:
> case MESA_FORMAT_ETC2_SIGNED_R11_EAC:
> @@ -1242,6 +1245,9 @@ _mesa_format_to_type_and_comps(mesa_format format,
> case MESA_FORMAT_BPTC_SRGB_ALPHA_UNORM:
> case MESA_FORMAT_BPTC_RGB_SIGNED_FLOAT:
> case MESA_FORMAT_BPTC_RGB_UNSIGNED_FLOAT:
> + case MESA_FORMAT_ATC_RGB:
> + case MESA_FORMAT_ATC_RGBA_EXPLICIT:
> + case MESA_FORMAT_ATC_RGBA_INTERPOLATED:
>/* XXX generate error instead? */
>*datatype = GL_UNSIGNED_BYTE;
>*comps = 0;
> @@ -2079,6 +2085,11 @@ _mesa_format_matches_format_and_type(mesa_format
> mesa_format,
> case MESA_FORMAT_ETC2_SRGB8_PUNCHTHROUGH_ALPHA1:
>return GL_FALSE;
>
> + case MESA_FORMAT_ATC_RGB:
> + case MESA_FORMAT_ATC_RGBA_EXPLICIT:
> + case MESA_FORMAT_ATC_RGBA_INTERPOLATED:
> + return GL_FALSE;
> +
> case MESA_FORMAT_A_SNORM8:
>return format == GL_ALPHA && type == GL_BYTE;
> case MESA_FORMAT_L_SNORM8:
> diff --git a/src/mesa/main/formats.csv b/src/mesa/main/formats.csv
> index e159e7d..1d669af 100644
> --- a/src/mesa/main/formats.csv
> +++ b/src/mesa/main/formats.csv
> @@ -301,3 +301,8 @@ MESA_FORMAT_BPTC_RGBA_UNORM , bptc , 4,
> 4, x128, , ,
> MESA_FORMAT_BPTC_SRGB_ALPHA_UNORM , bptc , 4, 4, x128, ,
> , , xyzw, srgb
> MESA_FORMAT_BPTC_RGB_SIGNED_FLOAT , bptc , 4, 4, x128, ,
> , , xyz1, rgb
> MESA_FORMAT_BPTC_RGB_UNSIGNED_FLOAT , bptc , 4, 4, x128, ,
> , , xyz1, rgb
> +
> +# ATC compressed formats
> +MESA_FORMAT_ATC_RGB , atc , 4, 4, x64 , ,
> , , xyz1, rgb
> +MESA_FORMAT_ATC_RGBA_EXPLICIT , atc , 4, 4, x128, ,
> , , xyzw, rgb
> +MESA_FORMAT_ATC_RGBA_INTERPOL
[Mesa-dev] [Bug 89330] piglit glsl-1.50 invariant-qualifier-in-out-block-01 regression
https://bugs.freedesktop.org/show_bug.cgi?id=89330 lu hua changed: What|Removed |Added CC||huax...@intel.com --- Comment #2 from lu hua --- I also see this fail. -- You are receiving this mail because: You are the QA Contact for the bug. 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 88907] [PNV Bisected]Ogles2conform ES2-CTS.gtf.GL2ExtensionTests.texture_float.texture_float segfault
https://bugs.freedesktop.org/show_bug.cgi?id=88907 lu hua changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from lu hua --- Test on the latest Mesa master branch, the core dumped issue goes away. output: dEQP Core GL-CTS-2.0 (0x0052484b) starting.. target implementation = 'X11' Test case 'ES2-CTS.gtf.GL2ExtensionTests.texture_float.texture_float'.. GL_OES_texture_float is not supported. Mesa 10.6.0-devel implementation error: unexpected format GL_RGB32F in _mesa_choose_tex_format() Please report at https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa #+ glTexImage2D: Got GL_NO_ERROR with internalformat=GL_RGB & type=GL_FLOAT. Expected GL_INVALID_ENUM Fail (Fail) DONE! Test run totals: Passed:0/1 (0.00%) Failed:1/1 (100.00%) Not supported: 0/1 (0.00%) Warnings: 0/1 (0.00%) -- 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 88907] [PNV Bisected]Ogles2conform ES2-CTS.gtf.GL2ExtensionTests.texture_float.texture_float segfault
https://bugs.freedesktop.org/show_bug.cgi?id=88907 lu hua changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #9 from lu hua --- Verified.Fixed. -- 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 88907] [PNV Bisected]Ogles2conform ES2-CTS.gtf.GL2ExtensionTests.texture_float.texture_float segfault
https://bugs.freedesktop.org/show_bug.cgi?id=88907 --- Comment #10 from Tapani Pälli --- The test still fails though, will you open a separate bug for that or will we handle it in the same one? -- 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
Re: [Mesa-dev] [RFC] configure.ac: Don't check for python mako module if python is not installed
On Sun, 2015-03-01 at 12:38 +, Emil Velikov wrote: > On 28/02/15 20:42, Matt Turner wrote: > > On Sat, Feb 28, 2015 at 3:10 AM, Emil Velikov > > wrote: > >> On 27/02/15 17:42, Matt Turner wrote: > >>> For flex and bison, we check if a generated source file exists, which > >>> is probably a good idea. That way configure will fail in a git > >>> checkout if you don't have python. > >>> > >> Checking for the presence of one auto-generated file does not sound like > >> a great idea imho. What happens if any of the other files is not present > >> - should we keep the whole list in configure.ac ? Keeping the list in > >> sync seems quite error prone. > > > > I copied the check-for-a-file pattern from libxkbcommon at the > > recommendation of Gaetan Nadon more than three years ago, and as far > > as I'm aware it's worked just fine. That's not to say that it's > > perfect, but claiming something that's been working fine for three > > years is "not a great idea" without offering a suggestion is a bit off > > putting. > > > There was a suggestion below which admittedly is quite a ugly one. From > a quick look at libxkbcommon, there has been a case where the file was > renamed, and the hunk was not updated. > > That said I think that trying to keep the list in sync is perhaps the > best thing we can do. The alternative solution from #autotools was to > just warn when python/lex/etc. is missing and fail at build stage. > > > > > Maybe I've misunderstood how this patch works. From the sound of > > "without Python it is going to fail anyway because Python is not > > present when trying to autogenerate the files" it seems that we're > > okay with not checking for mako if Python isn't present because > > running make is going to fail anyway? > > > > That doesn't sound like what we want -- it's configure's job to > > determine if we have the necessary dependencies for make to succeed. > > Yeah, this is one of the reasons I tagged it as RFC, this is a workaround that could be improved or trigger a discussion about a better solution :-) > To sum it all up, how does this sound: > > * Change ax_check_python_mako_module.m4 to set a variable, rather than > error out. This way we can have a bit more flexibility in configure.ac > * python is not found and X is not generated - error(you need python for X) > * python/mako is not found and Y is not generated - error(you need > python/mako for Y). Keeping the checks and error messages for python and > mako separate of course. > > I like it. If Matt agrees, I will modify ax_check_python_mako_module.m4 to set a variable. > > I'll think about this some more. > > > >> A hacky alternative is to set the variable (BISON/LEX/PYTHON2) to > >> something like `echo "Missing XXX dependency" && return 1` when empty. > >> Yet that looks quite nasty, plus it shows rather late in the build > >> process :\ > >> > >>> I have in my todo list to add some remaining source files generated by > >>> python to the autotools distribution. After we commit some version of > >>> this patch, Emil or I should make sure that all the python-generated > >>> code is included in the tarball. > >>> > >> I was under the impression that we already do, but I will double-check. > >> > >> > >> On a mildly related note: > >> For anyone that missed it Ken voiced concerns over shipping the > >> lex/bison generated files. Main idea is that as(if) security bugs are > >> found and fixed in those products, mesa has been released with such > >> vulnerable files. > >> I can see his point, and I tend to agree with him. How do others feel on > >> the topic ? > > > > Someone concerned should talk to the automake/bison/flex upstreams and > > see what they think. It is of course automake that adds the generated > > code to the distribution. > > > > We're certainly not the only project shipping code generated by flex and > > bison. > > > Ack. Just wanted to point out for anyone that was not in #dri-devel. > Perhaps we can carry on in a separate thread if/when needed. > I am not an autotools expert but if there is anything I can do to help, please do not hesitate to let me know. Sam signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 88907] [PNV Bisected]Ogles2conform ES2-CTS.gtf.GL2ExtensionTests.texture_float.texture_float segfault
https://bugs.freedesktop.org/show_bug.cgi?id=88907 --- Comment #11 from lu hua --- (In reply to Tapani Pälli from comment #10) > The test still fails though, will you open a separate bug for that or will > we handle it in the same one? It always fail, So closed this bug. Reported bug 89389 to track the fail. -- 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
