Re: [Mesa-dev] [Mesa-stable] [PATCH 1/2] configure.ac: strip out the llvm-config -march/mtune flags

Should probably also add mcpu for good measure - Chuck On Fri, Jun 10, 2016 at 1:54 PM, Emil Velikov wrote: > From: Emil Velikov > > Otherwise drivers such as SWR that depend on providing their own values > will fail to build. > > Cc:

Re: [Mesa-dev] [Mesa-stable] [PATCH 1/2] configure.ac: strip out the llvm-config -march/mtune flags

With the addition of mcpu: Reviewed-by: Chuck Atkins <chuck.atk...@kitware.com> Tested-by: Chuck Atkins <chuck.atk...@kitware.com> - Chuck On Fri, Jun 10, 2016 at 2:23 PM, Chuck Atkins <chuck.atk...@kitware.com> wrote: > Should probably also add mcpu for good measure &

[Mesa-dev] How to generate release source tarballs

What's the process for generating the release source tarballs? I'm trying to patch a problem with some missing SWR headers in the RC2 release. I believe I've fixed it but I need to generate a release source tarball first to make sure it's correct. - Chuck

[Mesa-dev] [PATCH] swr: Add missing headers for package inclusion

CC: "12.0" --- src/gallium/drivers/swr/Makefile.sources | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/src/gallium/drivers/swr/Makefile.sources b/src/gallium/drivers/swr/Makefile.sources index eb05c6f..f9448ee 100644 ---

Re: [Mesa-dev] [PATCH] swr: fix -march flag for AVX

> > Maybe I'm the only one who finds it horrible to override -march from > within project build systems. It causes no end of problems with LTO, > and results in objects being built inappropriately for the target as > specified by the builder. > In general I would agree, yes, but I think swr is a

Re: [Mesa-dev] [PATCH] mesa: Enable LTO compilation

On Tue, May 31, 2016 at 1:57 PM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote: > On Mon, May 30, 2016 at 9:27 PM, Emil Velikov > wrote: > > - Are you use the mapi hunk is needed ? last time I've tried (some > > months ago, copying the tweaks from the Clearlinux spec file [2]) >

Re: [Mesa-dev] [PATCH] mesa: Enable LTO compilation

> > > With gcc 5.3.1 I end up with lib{GL,OSMesa}.so @ 44M and > > libswrAVX{,2}.so @ 70M. With flto turned on it drops WAY down to > > lib{GL,OSMesa}.so @ 13M and libswrAVX{,2}.so @ 18M > > I assume those numbers are including debugging symbols? How do stripped > binaries compare? > Silly me, I

Re: [Mesa-dev] [PATCH] mesa: Enable LTO compilation

{GL,OSMesa}.so @ 13M and libswrAVX{,2}.so @ 18M - Chuck On Tue, May 31, 2016 at 10:57 AM, Emil Velikov <emil.l.veli...@gmail.com> wrote: > On 31 May 2016 at 15:34, Chuck Atkins <chuck.atk...@kitware.com> wrote: > >> I've been using lto for the past several weeks not fo

Re: [Mesa-dev] [PATCH] mesa: Enable LTO compilation

I've been using lto for the past several weeks not for performance reasons but to reduce the resulting binary size which has grown to be rather substantial. I usually set "-flto -ffat-lto-objects -flto-odr-type-merging" in the CFLAGS and CXXFLAGS env vars prior to configure and have yet to

Re: [Mesa-dev] [PATCH] swr: switch from overriding -march to selecting features

Using these adjusted flags, I can verify SWR running on Intel SandyBridge, Intel Haswell, and AMD Interlagos. Acked-by: Chuck Atkins <chuck.atk...@kitware.com> Tested-by: Chuck Atkins <chuck.atk...@kitware.com> - Chuck On Thu, Jun 16, 2016 at 4:07 PM, Tim Rowley <timothy.o.r

Re: [Mesa-dev] [PATCH 03/14] swr: [rasterizer] add support for building avx512 version

Doesn't this also need corresponding compiler flags in configure.ac to populate SWR_AVX512_CXXFLAGS? - Chuck On Fri, Jun 17, 2016 at 3:25 PM, Tim Rowley wrote: > Currently, most code paths between AVX2 and AVX512 are identical > (see changes to knobs.h). > --- >

Re: [Mesa-dev] [PATCH v2] swr: automake: don't ship LLVM version specific generated sources

So, I can confirm that with this patch applied to the rc3 tag, I can generate a tarball on Arch with make dist, and then use said tarball to build with SWR enabled on fedora. So: Tested-by: Chuck Atkins <chuck.atk...@kitware.com> - Chuck On Tue, Jun 14, 2016 at 1:14 PM, Emil V

Re: [Mesa-dev] [Mesa-stable] [PATCH] swr: fix -march flag for AVX

After some architecture testing, it looks like we can drop the march options and just enable the specific instruction sets via: libswrAVX: -mavx libswrAVX2: -mavx2 -mfma -mbmi2 -mf16c The benefit of course is that with these flags swr works on AMD cpu's with AVX and AVX2 instructions enabled.

Re: [Mesa-dev] [PATCH] swr: Update screen->context pointer with multiple contexts.

Hey, we've all made those commits at one point or another. +1 for code review! - Chuck On Fri, Jun 17, 2016 at 10:18 AM, Cherniak, Bruce wrote: > > > On Jun 17, 2016, at 8:56 AM, Rowley, Timothy O < > timothy.o.row...@intel.com> wrote: > > > > > >> On Jun 17, 2016,

Re: [Mesa-dev] [PATCH] include/GL: fix the interop header for a --disable-glx build

> > >> Drop the includes altogether, and forward declare the needed symbols. >> > > But then you end up with forward declarations of symbols that may not even > exist. > I guess you'll already have prototypes that will remain unresolved since if you're using GLX then you probably won't be linking

Re: [Mesa-dev] [PATCH] include/GL: fix the interop header for a --disable-glx build

> > >> Drop the includes altogether, and forward declare the needed symbols. > But then you end up with forward declarations of symbols that may not even exist. > > Why not use the configure.ac-based approach suggested by Chuck? > > Few reasons come to mind: > > Not to mention that every user

Re: [Mesa-dev] [PATCH 1/3] glx: Implement the libglvnd interface.

> > +if test "x$enable_glx" = xno; then > +AC_MSG_ERROR([cannot build libglvnd without GLX]) > +fi > + > +if test "x$enable_xlib_glx" = xyes; then > +AC_MSG_ERROR([cannot build libgvnd when Xlib-GLX is enabled]) > +fi > This doesn't consider the gallium-xlib

Re: [Mesa-dev] [PATCH] swr: fix swr linkage so that static llvm works

This patch was in response to an issue I raised to Tim and it fixed it for me so Tested-by: Chuck Atkins <chuck.atk...@kitware.com> - Chuck On Mon, May 16, 2016 at 2:31 PM, Tim Rowley <timothy.o.row...@intel.com> wrote: > --- > src/gallium/drivers/swr/Makefile.am | 11 +++

Re: [Mesa-dev] [PATCH] swr: fix swr linkage so that static llvm works

> > Then again, I doubt that this issue is static llvm specific. Most > likely in the shared llvm case, we were producing libraries with > unresolved symbols and those were implicitly resolved by something > else ? > With swr specifically, the implementation is broken out into a separate

Re: [Mesa-dev] [PATCH] glx: Refactor the configure options for glx implementation choice

> > but it seems to me that things should be getting built if they can't be > safely installed. > Err: things should not be getting built if they can't be safely installed. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org

Re: [Mesa-dev] [PATCH] gallium/swr: confine c++11 flag to swr driver

> > > As LLVM_CXXFLAGS / `llvm-config --cxxflags` already includes std=c++11 > > Yes, I saw that and considered going that direction, but wasn’t sure if we > should rely on llvm setting the language version required. > Shouldn't you do both? Use LLVM_CXXFLAGS since swr is C++ code including and

Re: [Mesa-dev] [PATCH] glx: Refactor the configure options for glx implementation choice

an one is specified then generate a configure-time warning and leave them out of the install target but it seems to me that things should be getting built if they can't be safely installed. - Chuck On Fri, Apr 15, 2016 at 12:08 PM, Brian Paul <bri...@vmware.com> wrote: > On 04/15/2016 09:36 A

Re: [Mesa-dev] [PATCH 2/2] configure: Add support for the Intel Vulkan driver

> > > Put x in front of everything: > > > Which reminds me - what are the advantages of it ? In the gallium > drivers (where this is derived from) and I've not seen any issues. > Mostly curious, I'm fine with or without the x. > It prevents empty string problems. If the variable is undefined or

[Mesa-dev] [PATCH] glx: Refactor the configure options for glx implementation choice

Instead of cascading support for various different implementations of GLX, all three options are now specified through the --enable-glx option: --enable-glx=dri : Enable the DRI-based GLX --enable-glx=xlib : Enable the classic Xlib-based GLX --enable-glx=gallium-xlib :

[Mesa-dev] [PATCH] glx configure refactor: single-option verion

mentations getting specified and in my opinion, reduces the complexity of an already large and complex set of configure options. I gave both implementations though depending on how the reviewing developer (Emil?) would would like to see it. Chuck Atkins (1): glx: Refactor the configure optio

Re: [Mesa-dev] [PATCH] glx: Refactor the configure options for glx implementation choice

14, 2016 at 3:44 PM, Chuck Atkins <chuck.atk...@kitware.com> wrote: > Instead of cascading support for various different implementations of > GLX, all three options are now mutually exclusive top level options: > > --enable-glx : Enable the DRI-based GLX &

Re: [Mesa-dev] [PATCH] glx: Refactor the configure options for glx implementation choice

On Fri, Apr 15, 2016 at 2:07 PM, Emil Velikov <emil.l.veli...@gmail.com> wrote: > On 15 April 2016 at 16:36, Chuck Atkins <chuck.atk...@kitware.com> wrote: > > Instead of cascading support for various different implementations of > > GLX, all three options are now spe

[Mesa-dev] [PATCH] glx: Refactor the configure options for glx implementation choice (v2)

(Sorry about the bad line wraps in the first one) Instead of cascading support for various different implementations of GLX, all three options are now specified through the --enable-glx option: --enable-glx=dri : Enable the DRI-based GLX --enable-glx=xlib : Enable the

[Mesa-dev] [PATCH] glx: Refactor the configure options for glx implementation choice (v2)

Instead of cascading support for various different implementations of GLX, all three options are now specified through the --enable-glx option: --enable-glx=dri : Enable the DRI-based GLX --enable-glx=xlib : Enable the classic Xlib-based GLX --enable-glx=gallium-xlib :

Re: [Mesa-dev] [PATCH] configure.ac: fix the --disable-llvm-shared-libs build

This still doesn't quite give what you want. One can also have an llvm with component shared libs. So there's three different options for llvm library configurations: a single shared lib, component shared libs, or component static libs. To ensure you're getting just the static libs or just the

[Mesa-dev] [PATCH] glx: Refactor the configure options for glx implementation choice (v3)

Instead of cascading support for various different implementations of GLX, all three options are now specified through the --enable-glx option: --enable-glx=dri : Enable the DRI-based GLX --enable-glx=xlib : Enable the classic Xlib-based GLX --enable-glx=gallium-xlib :

Re: [Mesa-dev] [PATCH] swr: fix resource backed constant buffers

While i never got this error in the first place, I can attest that it certainly hasn't broken any use in paraview, so... Tested-by: Chuck Atkins <chuck.atk...@kitware.com> - Chuck On Tue, Apr 19, 2016 at 1:45 AM, Markus Wick <mar...@selfnet.de> wrote: > Am 2016-04-19 01:12, sch

[Mesa-dev] [PATCH] glx: Refactor the configure options for glx implementation choice

Instead of cascading support for various different implementations of GLX, all three options are now mutually exclusive top level options: --enable-glx : Enable the DRI-based GLX --enable-xlib-glx: Enable the classic Xlib-based GLX --enable-gallium-xlib-glx: Enable the gallium

Re: [Mesa-dev] [PATCH] include/GL: fix the interop header for a --disable-glx build

> > The MESA_EGL_NO_X11_HEADERS macro is used to check if we're building > without > GLX support. > In configure.ac: # If we don't have the X11 platform, set this define so we don't try to include # the X11 headers. if ! echo "$egl_platforms" | grep -q 'x11'; then DEFINES="$DEFINES

Re: [Mesa-dev] [Mesa-stable] [PATCH] Revert "gallium: Force blend color to 16-byte alignment"

Acked-by: Chuck Atkins <chuck.atk...@kitware.com> - Chuck On Wed, Jul 13, 2016 at 11:39 AM, Tim Rowley <timothy.o.row...@intel.com> wrote: > This reverts commit d8d6091a846ac2a40a011d512d6d57f6c8442e6a. > > Cc: <mesa-sta...@lists.freedesktop.org> > Signed-off

Re: [Mesa-dev] [PATCH] gallium: Fix blend color alignment for 32-bit systems

gt;>> Rather than track down and fix all allocation sites where a >>> pipe_blend_color >>> may be embedded, assume that the original compiler bug only affects >>> 64-bits. >>> >>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96835 >&

[Mesa-dev] [PATCH] swr: Refactor checks for compiler feature flags

instruction feature flags and then potentially fail to build. v2: Pass preprocessor-check argument as true-state instead of false-state for clarity. Cc: Tim Rowley <timothy.o.row...@intel.com> Signed-off-by: Chuck Atkins <chuck.atk...@kitware.com> --- confi

Re: [Mesa-dev] [PATCH] swr: Refactor checks for compiler feature flags

the additional 2 instructions. - Chuck On Tue, Jun 28, 2016 at 1:52 PM, Rowley, Timothy O < timothy.o.row...@intel.com> wrote: > > > On Jun 28, 2016, at 8:24 AM, Chuck Atkins <chuck.atk...@kitware.com> > wrote: > > > > Encapsulate the test for which flags are needed to g

[Mesa-dev] [PATCH v3] swr: Refactor checks for compiler feature flags

w.r.t thier availability. Cc: Tim Rowley <timothy.o.row...@intel.com> Signed-off-by: Chuck Atkins <chuck.atk...@kitware.com> --- configure.ac | 86 +++- 1 file changed, 62 insertions(+), 24 deletions(-) diff --git a/co

Re: [Mesa-dev] [PATCH] swr: Refactor checks for compiler feature flags

ild wither. - Chuck On Tue, Jun 28, 2016 at 2:10 PM, Chuck Atkins <chuck.atk...@kitware.com> wrote: > So this seems to be different across versions as well. It looks like > __AVX__ and __AVX2__ are the only ones we can really count on being there. > I can drop the second check to jus

[Mesa-dev] [PATCH v4] swr: Refactor checks for compiler feature flags

w.r.t thier availability. v4: Fix C++11 flags being added globally and add more logic to swr_require_cxx_feature_flags Cc: Tim Rowley <timothy.o.row...@intel.com> Signed-off-by: Chuck Atkins <chuck.atk...@kitware.com> --- configure.ac

[Mesa-dev] [PATCH] gallium: Force blend color to 16-byte alignment

This aligns the 4-element color float array to 16 byte boundaries. This should allow compiler vectorizers to generate better optimizations. Also fixes broken vectorization generated by Intel compiler. Reported-by: Tim Rowley <timothy.o.row...@intel.com> Signed-off-by: Chuck Atkins <

[Mesa-dev] [PATCH] swr: Refactor checks for compiler feature flags

instruction feature flags and then potentially fail to build. Cc: Tim Rowley <timothy.o.row...@intel.com> Signed-off-by: Chuck Atkins <chuck.atk...@kitware.com> --- configure.ac | 86 +++- 1 file changed, 62 insertions(+), 24 deleti

[Mesa-dev] [PATCH v2] gallium: Force blend color to 16-byte alignment

. Reported-by: Tim Rowley <timothy.o.row...@intel.com> Tested-by: Tim Rowley <timothy.o.row...@intel.com> Signed-off-by: Chuck Atkins <chuck.atk...@kitware.com> Acked-by: Roland Scheidegger <srol...@vmware.com> --- src/gallium/include/pipe/p_state.h | 12 +++- 1 fil

Re: [Mesa-dev] [PATCH] gallium: Force blend color to 16-byte alignment

the patch with a comment explaining why it's there in case other developers stumble on it and think "wtf". On Jun 28, 2016 6:38 PM, "Roland Scheidegger" <srol...@vmware.com> wrote: Am 28.06.2016 um 22:45 schrieb Chuck Atkins: > This aligns the 4-element color floa

Re: [Mesa-dev] [PATCH v2] gallium: Force blend color to 16-byte alignment

I just wanted to avoid it getting removed later on because somebody sees it as an unnecessary micro-optimization providing no real benefit. - Chuck On Wed, Jun 29, 2016 at 7:49 PM, Roland Scheidegger <srol...@vmware.com> wrote: > Am 29.06.2016 um 04:32 schrieb Chuck Atkins: > &

Re: [Mesa-dev] [PATCH v4] swr: Refactor checks for compiler feature flags

> > This part should have been a separate patch. Please try to keep things > separate for the future. > Indeed, I should have this as two separate commits, one to encapsulate the flag test and another to add additional options to test for. I'll keep them more segmented in the future. > Esp

[Mesa-dev] [PATCH] swr: clean up c++ feature flag test to not deal with IFS

Cc: Tim Rowley <timothy.o.row...@intel.com> Signed-off-by: Chuck Atkins <chuck.atk...@kitware.com> --- configure.ac | 43 ++- 1 file changed, 18 insertions(+), 25 deletions(-) diff --git a/configure.ac b/configure.ac index 8321e8e..84

Re: [Mesa-dev] [PATCH 7/8] configure.ac: disable enable_gallium_llvm in the !x86 case

Forgive me, as I'm not too familiar with the rest of the infrastructure surrounding this, but what's the motivation for disabling llvm on non-x86 given that llvm itself is available on a wide variety of platforms? -- Chuck Atkins Staff R Engineer, Scientific Computing Kitware, Inc. (518

Re: [Mesa-dev] [PATCH] autoconf: Make header install distinct for various APIs

> > > +eglinterop_HEADERS = $(top_srcdir)/include/GL/mesa_glinterop.h > IIRC Marek was pretty clear that this header should not be installed. > Then again looking at our current wildcard installing ... seems like > it was. > > Please drop this file from the install stage ? > Dropped. > +if

Re: [Mesa-dev] [PATCH] autoconf: Make header install distinct for various APIs (v2)

Ping? On Oct 4, 2016 11:05 AM, "Chuck Atkins" <chuck.atk...@kitware.com> wrote: > This fixes a problem where GL headers would only get installed if > glx was enabled. So if osmesa was enabled but not glx, then the > GL headers required by osmesa would be missing

[Mesa-dev] [PATCH] autoconf: Make header install distinct for various APIs (v2)

eli...@gmail.com> Signed-off-by: Chuck Atkins <chuck.atk...@kitware.com> --- configure.ac | 2 ++ src/Makefile.am | 24 src/mesa/Makefile.am | 10 -- 3 files changed, 26 insertions(+), 10 deletions(-) diff --git a/configure.ac b/configure.ac i

[Mesa-dev] [PATCH] autoconf: Make header install distinct for various APIs

This fixes a problem where GL headers would only get installed if glx was enabled. So if osmesa was enabled but not glx, then the GL headers required by osmesa would be missing from the install. Signed-off-by: Chuck Atkins <chuck.atk...@kitware.com> --- configure.ac| 2 +

Re: [Mesa-dev] [PATCH] autoconf: Make header install distinct for various APIs

Ping? On Sep 30, 2016 2:37 PM, "Chuck Atkins" <chuck.atk...@kitware.com> wrote: > This fixes a problem where GL headers would only get installed if > glx was enabled. So if osmesa was enabled but not glx, then the > GL headers required by osmesa would be missing from th

[Mesa-dev] General safety of building with O3 instead of O2

ime issues from this but default behavior of Mesa seems to be O2. Are there any known issues using O3 for Mesa GLX / OSMesa with llvmpipe and swr? Thanks - Chuck ------ Chuck Atkins Staff R Engineer, Scientific Computing Kitware, Inc. ___ mesa-dev ma

Re: [Mesa-dev] LLVM gallivm issue in Mesa 12.1.0

> Perhaps we need to make sure we pick --std=c++11. > > But this also implies that *all* Mesa needs to build reliably with > --std=c++11. Yes, that is correct. The issue is one of C++11 ABI mismatch. If a public interface to a library is C++ but contains no C++ std library data structures

Re: [Mesa-dev] [PATCH] gallium/os: Use unsigned integers for size computation

Shouldn't' the size argument itself be size_t instead of uint64_t? - Chuck On Tue, Oct 11, 2016 at 12:59 PM, Axel Davy wrote: > Use uint64_t instead of int64_t in the calculation, > as the result is uint64_t. > > Signed-off-by: Axel Davy > --- > This

Re: [Mesa-dev] [PATCH] glx: Add missing glproto dependency for gallium-xlib glx

Just saw this got merged, thanks! Any chance of it getting to stable for the 13.1 release? -- Chuck Atkins Staff R Engineer, Scientific Computing Kitware, Inc. On Mon, Jan 9, 2017 at 11:10 PM, Cherniak, Bruce <bruce.chern...@intel.com> wrote: > This comes in very handy on

Re: [Mesa-dev] [Mesa-stable] [PATCH] glx: Add missing glproto dependency for gallium-xlib glx

Hi Emil, > It will land for 13.0, Excellent! Sorry for the confusion. That's what I was looking for. It caused specific pains for deploying on "older" Cray systems, whch are a large part of my userbase. This way I can stop patching the builds and move to an actual release. > but I can

[Mesa-dev] [PATCH] glx: Add missing glproto dependency for gallium-xlib glx

Cc: mesa-sta...@lists.freedesktop.org Cc: Bruce Cherniak <bruce.chern...@intel.com> Signed-of-by: Chuck Atkins <chuck.atk...@kitware.com> --- configure.ac| 4 +++- src/gallium/state_trackers/glx/xlib/Makefile.am | 1 + 2 files changed, 4 inse

[Mesa-dev] [PATCH] swr: Add arch flags to support Cray and PGI compilers

-by: Chuck Atkins <chuck.atk...@kitware.com> Cc: Tim Rowley <timothy.o.row...@intel.com> --- configure.ac | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/configure.ac b/configure.ac index 6302aa2b0c..3b45baf6d0 100644 --- a/configure.ac +++ b/configure.ac @@ -25

Re: [Mesa-dev] [PATCH] swr: Add arch flags to support Cray and PGI compilers

quirks and oddities of the Cray Programming Environment. > I’m guessing you intend this for the 17.2 branch as well? > Nope. I've no pressing customer need for it so keeping it in master but out of stable is fine with me. -- Chuck Atkins Staff R Engineer, Scientif

Re: [Mesa-dev] [PATCH 2/2] configure.ac: drop support for ancient expat versions

I was a bit confused by this at first but I think I understand it. Just to clarify, this isn't actually dropping support for any version of expat, it's just dropping support for automatic detection without a pkg-config file, which coincidentally started shipping in 2.1.0. But it's not like

Re: [Mesa-dev] [PATCH 2/2] configure.ac: drop support for ancient expat versions

> So if > > you did happen to have an older expat version that you manually created a > > .pc file for, then things should build and work just fine, barring of > course > > any expat bugs from untested older versions. Do I have that right? > > > Right - the version and .pc is more of a happy

Re: [Mesa-dev] [Mesa-stable] [PATCH] configure: remove trailing "-a" in swr architecture test

I hit this a few weeks ago when I was adding the cray flags to swr and patched it manually but forgot to push it upstream. Thanks for the fix. Tested-by: Chuck Atkins <chuck.atk...@kitware.com> - Chuck On Thu, Aug 10, 2017 at 2:04 PM, Matt Turner <matts...@gmail.com> wrote:

[Mesa-dev] Bug in 17.1.0-rc4 source packaging for swr?

I just tried to build 17.0.4-rc4 from the tarball with swr enabled and got errors about my python not having mako: make[5]: Entering directory '/tmp/atkins3/mesa/build/mesa-17.1.0-rc4_gcc-6.3.0_haswell/src/gallium/drivers/swr' GEN rasterizer/jitter/gen_builder.hpp Traceback (most recent

Re: [Mesa-dev] Mesa 17.1.1 release candidate

> > The candidate for the Mesa 17.1.1 is now available. Excellent! >From build perspective - SWR now ships it's final generated header, thus > Python/mako is no longer required. > Just what I was looking for, thanks! Is a source tarball available that I can test the build with? I would just

Re: [Mesa-dev] Bug in 17.1.0-rc4 source packaging for swr?

vm40.hpp" #elif llvm_version >= 3.9 #include "gen_builder_llvm39.hpp" #elif llvm_version >= 3.8 #include "gen_builder_llvm38.hpp" #else #error llvm version >= 3.8 is required #elif Using the appropriate version checks of course (this is just pseudo code to show the

[Mesa-dev] [PATCH] Reduce zlib requirement from 1.2.8 to 1.2.3.

Testing with zlib versions 1.2.{3,4,5,6,7,8} showed no difference in functionality, correctness, or zlib API usage and 1.2.3 is the oldest version available in still actively deployed production Linux distributions (RHEL/CentOS 6 and SuSE 11). Signed-off-by: Chuck Atkins <chuck.atk...@kitware.

Re: [Mesa-dev] [Mesa-stable] [PATCH] Reduce zlib requirement from 1.2.8 to 1.2.3.

Hi Emil, Did you test the upstream versions or the distribution ones which tend > to be patched? > Both. I build 17.1.1 against the system supplied zlib-devel packages for 1.2.3 in EL6 and 1.2.7 on EL7. I then swapped out the zlib version at runtime via LD_LIBRARY_PATH with ones build from the

Re: [Mesa-dev] [Mesa-stable] [PATCH] Reduce zlib requirement from 1.2.8 to 1.2.3.

Thanks Emil. I assume this is fine for 17.1 stable as well then? - Chuck On Wed, Jun 14, 2017 at 7:14 AM, Emil Velikov <emil.l.veli...@gmail.com> wrote: > On 9 June 2017 at 16:00, Chuck Atkins <chuck.atk...@kitware.com> wrote: > > Hi Emil, > > > >>

Re: [Mesa-dev] Mesa 17.1.1 release candidate

> > We don't do release tarballs for the stable RC. Although it has been > asked a few times in the past. > There's nothing stopping us though - will check if we can start doing so. > With most codes, I would normally be happy with just using the git tag but most of the issues I run into tend to

Re: [Mesa-dev] [PATCH v4 0/2] build system: Unify c++11 detection and used [was: configure+mesa/st:check -std=c++11 support and enable tests accordingly]

Hi Gert, Emil, I think that using the -std=c++11 check should be good, A few things to consider, neither of which is a deal breaker, I just want to make sure they're not forgotten about: 1. -std=c++ will cover many cases, but not all. Many commercial compilers use a different set of

Re: [Mesa-dev] [PATCH v4 0/2] build system: Unify c++11 detection and used [was: configure+mesa/st:check -std=c++11 support and enable tests accordingly]

> > I also think adding a test for each C++11 feature used in the code is > too tedious, regardless of the build system, and it would really need a > dedicated maintainer. > Certainly. Rather than checking for everything, I think a code snippet that just includes a few c++11-only headers would

Re: [Mesa-dev] [PATCH] mesa: Unconditionally enable floating-point textures

n floating point textures in our distributed binaries without assuming shifting legal risk ------ Chuck Atkins Staff R Engineer, Scientific Computing Kitware, Inc. On Sat, Jun 16, 2018 at 9:10 PM Ian Romanick wrote: > Reviewed-by: Ian Romanick > > I'd also be in favor of a patch f

Re: [Mesa-dev] [PATCH 2/3] swr: allow a single swr architecture to be builtin

018, at 1:59 PM, Chuck Atkins <chuck.atk...@kitware.com> > wrote: > > > > Part 2 of 2 (part 1 is autoconf changes, part 2 is C++ changes) > > > > When only a single SWR architecture is being used, this allows that > > architecture to be builtin rather tha

[Mesa-dev] [PATCH 1/2] swr: (autoconf) allow a single swr architecture to be builtin

of thousands of copies of the libs are loaded from a shared parallel filesystem. Based on an initial implementation by Tim Rowley. v2: Fix comment placement pointed out by Bruce C. Signed-off-by: Chuck Atkins <chuck.atk...@kitware.com> Reviewed-by: Bruce Cherniak <bruce.chern...@intel.com> CC

[Mesa-dev] [PATCH 2/2] swr: allow a single swr architecture to be builtin

of thousands of copies of the libs are loaded from a shared parallel filesystem. Based on an initial implementation by Tim Rowley. v2: Refactor repetitive preprocessor checks to reduce code duplication Signed-off-by: Chuck Atkins <chuck.atk...@kitware.com> Reviewed-by: Bruce Cherniak <br

Re: [Mesa-dev] [PATCH 1/3] swr: (autoconf) allow a single swr architecture to be builtin

ed-by: Bruce Cherniak <bruce.chern...@intel.com> > > > On Jan 16, 2018, at 1:59 PM, Chuck Atkins <chuck.atk...@kitware.com> > wrote: > > > > Part 1 of 2 (part 1 is autoconf changes, part 2 is C++ changes) > > > > When only a single SWR architecture is being

Re: [Mesa-dev] [PATCH 3/3] swr: suppress debug output from loader unless LIBGL_DEBUG is set.

I think actually I'll drop this commit entirely. Really it should be it's own stand-alone topic and probably be more pervasive than just the loader. - Chuck <(518)%20881-1183> On Tue, Jan 16, 2018 at 2:59 PM, Chuck Atkins <chuck.atk...@kitware.com> wrote: > Signed-off-b

Re: [Mesa-dev] [PATCH 2/3] swr: allow a single swr architecture to be builtin

Since there's been some churn on this, I'll try to post the updated patches in a new thread (provided my git config is set right that is) - Chuck On Wed, Jan 17, 2018 at 8:56 AM, Chuck Atkins <chuck.atk...@kitware.com> wrote: > I wasn't happy with the redundancy either but at the

[Mesa-dev] [PATCH 1/2] swr: (autoconf) allow a single swr architecture to be builtin

of thousands of copies of the libs are loaded from a shared parallel filesystem. Based on an initial implementation by Tim Rowley. v2: Fix comment placement pointed out by Bruce C. Signed-off-by: Chuck Atkins <chuck.atk...@kitware.com> Reviewed-by: Bruce Cherniak <bruce.chern...@intel.com> CC

[Mesa-dev] [PATCH 2/2] swr: allow a single swr architecture to be builtin

conditions are hit. Signed-off-by: Chuck Atkins <chuck.atk...@kitware.com> Reviewed-by: Bruce Cherniak <bruce.chern...@intel.com> CC: Tim Rowley <timothy.o.row...@intel.com> --- src/gallium/drivers/swr/swr_loader.cpp | 84 -- 1 file changed, 49

[Mesa-dev] [PATCH 2/2] swr: suppress debug output from loader unless LIBGL_DEBUG is set.

Signed-off-by: Chuck Atkins <chuck.atk...@kitware.com> CC: Tim Rowley <timothy.o.row...@intel.com> CC: Bruce Cherniak <bruce.chern...@intel.com> --- src/gallium/drivers/swr/swr_loader.cpp | 41 +- 1 file changed, 25 insertions(+), 16 deletions(-)

[Mesa-dev] [PATCH 1/2] swr: allow a single architecture to be builtin

filesystem. Based on an initial implementation by Tim Rowley. Signed-off-by: Chuck Atkins <chuck.atk...@kitware.com> CC: Tim Rowley <timothy.o.row...@intel.com> CC: Bruce Cherniak <bruce.chern...@intel.com> --- configure.ac | 12 - src/gallium/drive

Re: [Mesa-dev] [PATCH 12/14] swr: build on FreeBSD/DragonFlyBSD

Hi Emil, Greg, > > (Needs CPU topology detection to actually work) > Does it? Or does it just need the topology detection for the current "default" behavior for thread placement? The default behavior for swr is to use the cpu topology info to place one thread per core and pin it to that

[Mesa-dev] Logging infrastructure?

Is there a logging infrastructure currently available to drivers in Mesa? I was looking to clean up some of swr's debug / info output and have it conditional on the MESA_DEBUG and LIBGL_DEBUG variables but then I realized that it's really something useful all across mesa so there may already be

[Mesa-dev] [PATCH] configure.ac: add missing llvm dependencies to .pc files

CC: <mesa-sta...@lists.freedesktop.org> Signed-of-by: Chuck Atkins <chuck.atk...@kitware.com> --- configure.ac | 12 1 file changed, 12 insertions(+) diff --git a/configure.ac b/configure.ac index 7c1fbe0ed1..e1be7b78e4 100644 --- a/configure.ac +++ b/configure.a

Re: [Mesa-dev] [Mesa-stable] [PATCH v2] configure.ac: add missing llvm dependencies to .pc files

Hi Emil, I'll squash it before pushing >> > > Thanks! Hopefully once my new account goes through I can push on my own. > It looks like my account finally went through so I can just take care of pushing it myself. - Chuck ___ mesa-dev mailing list

Re: [Mesa-dev] [Mesa-stable] [PATCH v2] configure.ac: add missing llvm dependencies to .pc files

> > > +if test "x$enable_glx" == xgallium-xlib; then > > +GL_PC_LIB_PRIV="$GL_PC_LIB_PRIV $LLVM_LIBS" > > +fi > > +if test "x$enable_gallium_osmesa" = xyes; then > > +OSMESA_PC_LIB_PRIV="$OSMESA_PC_LIB_PRIV $LLVM_LIBS" > > +fi > I'm itching to add a comment above

Re: [Mesa-dev] [Mesa-stable] [PATCH] configure.ac: add missing llvm dependencies to .pc files

> Should be used only for gallium-xlib based glx, since it embeds the > swr/llvmpipe driver. > ... ... > There is no LLVM specific code in these - ^^ should not be needed. > Correct. This was initially to address the problem for OSMesa but I realized it was likely an issue for more than just

[Mesa-dev] [PATCH v2] configure.ac: add missing llvm dependencies to .pc files

v2: Only add as dependencies for gallium-osmesa and gallium-xlib CC: <mesa-sta...@lists.freedesktop.org> Signed-of-by: Chuck Atkins <chuck.atk...@kitware.com> --- configure.ac | 6 ++ 1 file changed, 6 insertions(+) diff --git a/configure.ac b/configure.ac index 7c1fbe0ed1

Re: [Mesa-dev] [PATCH] swr: don't export swr_create_screen_internal

Lgtm, should probably get a rb from Intel though to make sure it doesn't break anything they're trying to do. Tested-by: Chuck Atkins <chuck.atk...@kitware.com> On Jan 29, 2018 07:09, "Emil Velikov" <emil.l.veli...@gmail.com> wrote: On 22 January 2018 at 17:52, Emi

Re: [Mesa-dev] [Mesa-stable] [PATCH] glx: Properly handle cases where screen creation fails

> > Something doesn't look quite right - it seems that xmesa_init_display > should be fixed instead. > > Currently it returns non-NULL when either of the following fail: > - driver.create_pipe_screen() > - CALLOC_STRUCT > > I would add an explicit check after those + goto err_path. > The latter

[Mesa-dev] [PATCH] glx: Properly handle cases where screen creation fails

This fixes a segfault exposed by a29d63ecf7 which occurs when swr is used on an unsupported architecture. Signed-off-by: Chuck Atkins <chuck.atk...@kitware.com> Cc: mesa-sta...@lists.freedesktop.org Cc: George Kyriazis <george.kyria...@intel.com> Cc: Bruce Cherniak <bruce.che

Re: [Mesa-dev] [Mesa-stable] [PATCH] glx: Properly handle cases where screen creation fails

Sorry for the repeat, I was adding the Intel devs to the CC list since it's related to swr -Chuck On Wed, Feb 21, 2018 at 9:26 AM, Chuck Atkins <chuck.atk...@kitware.com> wrote: > This fixes a segfault exposed by a29d63ecf7 which occurs when swr is > used on an unsupported

Re: [Mesa-dev] [PATCH] glx: Properly handle cases where screen creation fails

> > - if (xmdpy->smapi->destroy) > > - xmdpy->smapi->destroy(xmdpy->smapi); > > - free(xmdpy->smapi); > > + if (xmdpy->smapi) > > + { > > + if (xmdpy->smapi->destroy) > > + xmdpy->smapi->destroy(xmdpy->smapi); > > + free(xmdpy->smapi); > > + } > > I don't know this

[Mesa-dev] [PATCH] glx: Properly handle cases where screen creation fails

This fixed a segfault exposed by a29d63ecf7 which occurs when swr is used on an unsupported architecture. Signed-off-by: Chuck Atkins <chuck.atk...@kitware.com> Cc: mesa-sta...@lists.freedesktop.org --- src/gallium/state_trackers/glx/xlib/xm_api.c | 11 +++ 1 file changed, 7 inse

Re: [Mesa-dev] [PATCH mesa] docs: fix patent url

FWIW, the patent should expire this June in which case it should no longer be an issue. On Tue, Feb 20, 2018 at 10:00 AM, Emil Velikov wrote: > On 20 February 2018 at 13:36, Eric Engestrom > wrote: > > Reported-by: Pierre Moreau

Re: [Mesa-dev] [PATCH mesa] docs: fix patent url

> > On 20 February 2018 at 17:20, Chuck Atkins <chuck.atk...@kitware.com> > wrote: > > FWIW, the patent should expire this June in which case it should no > longer > > be an issue. > > > I think you're confusing "application fill-in date" with "

  1   2   >