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
---
configure.ac| 2 ++
src/Makefile.am | 30
Ping?
On Sep 30, 2016 2:37 PM, "Chuck Atkins" 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 the install.
>
> Si
>
> > +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 HAVE_
: Chuck Atkins
---
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
index 1bfac3b..c7be735 100644
--- a/configure.ac
+++ b/configure.ac
Ping?
On Oct 4, 2016 11:05 AM, "Chuck Atkins" 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 the install.
>
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 corrects the small mistake from
> 21845977
d any runtime 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&D Engineer, Scientific Computing
Kitware, Inc.
> 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 (rar
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
wrote:
> Am 29.06.2016 um 04:32 schrieb Chuck Atkins:
> > This aligns the 4-elem
>
> 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 wit
Cc: Tim Rowley
Signed-off-by: Chuck Atkins
---
configure.ac | 43 ++-
1 file changed, 18 insertions(+), 25 deletions(-)
diff --git a/configure.ac b/configure.ac
index 8321e8e..844e91c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2331,37 +2331,30
an 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
>>> Cc: Tim Rowley
>>> Cc
Acked-by: Chuck Atkins
- Chuck
On Wed, Jul 13, 2016 at 11:39 AM, Tim Rowley
wrote:
> This reverts commit d8d6091a846ac2a40a011d512d6d57f6c8442e6a.
>
> Cc:
> Signed-off-by: Tim Rowley
> ---
> src/gallium/include/pipe/p_state.h | 12 +---
> 1 file change
dependencies of the software rasterizers since
you should be able to build a libOSMesa.so with only software rasterizers,
i.e. softpipe, llvmpipe, and swr, without requiring any windowing system.
------
Chuck Atkins
Staff R&D Engineer, Scientific Computing
Kitw
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
14, 2016 at 3:44 PM, Chuck Atkins
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
> --enable-xlib-glx: Enable t
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 : Enabl
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
>
> > 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 us
than 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 wrote:
> On 04/15/2016 09:36 AM, Chuck Atkins
>
> 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
https://lists.freedeskto
>
> > 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
e
On Fri, Apr 15, 2016 at 2:07 PM, Emil Velikov
wrote:
> On 15 April 2016 at 16:36, Chuck Atkins wrote:
> > Instead of cascading support for various different implementations of
> > GLX, all three options are now specified through the --enable-glx
> > option:
> >
>
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 : Enabl
(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 classic
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 : Enabl
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 s
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
On Tue, Apr 19, 2016 at 1:45 AM, Markus Wick wrote:
> Am 2016-04-19 01:12, schrieb Tim Rowley:
>
>> Code was using an inco
>
> 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 -DMESA_EGL
>
> >> 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
>
> >> 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
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 experie
o lib{GL,OSMesa}.so @ 13M and
libswrAVX{,2}.so @ 18M
- Chuck
On Tue, May 31, 2016 at 10:57 AM, Emil Velikov
wrote:
> On 31 May 2016 at 15:34, Chuck Atkins wrote:
>
>> I've been using lto for the past several weeks not for performance
>> reasons but to reduce the resulting
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])
> > things built without issu
>
> > 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
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
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
--- a/src/gallium/drivers/swr/Makefile.sources
+
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: "11.2 12.0"
> Cc: Tim Rowley
> Signed-off-by: Emil Veliko
With the addition of mcpu:
Reviewed-by: Chuck Atkins
Tested-by: Chuck Atkins
- Chuck
On Fri, Jun 10, 2016 at 2:23 PM, Chuck Atkins
wrote:
> Should probably also add mcpu for good measure
>
> - Chuck
>
> On Fri, Jun 10, 2016 at 1:54 PM, Emil Velikov
> wrote:
>
>
> 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
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
On Tue, Jun 14, 2016 at 1:14 PM, Emil Velikov
wrote:
> On 14 June 2016 at 18
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. Th
Using these adjusted flags, I can verify SWR running on Intel SandyBridge,
Intel Haswell, and AMD Interlagos.
Acked-by: Chuck Atkins
Tested-by: Chuck Atkins
- Chuck
On Thu, Jun 16, 2016 at 4:07 PM, Tim Rowley
wrote:
> ---
> configure.ac| 11 +++
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, at 8:58 AM, Bruce Cherniak
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).
> ---
> src/gallium/drivers/swr/rasteri
AVX2 instruction feature flags and then potentially fail to build.
Cc: Tim Rowley
Signed-off-by: Chuck Atkins
---
configure.ac | 86 +++-
1 file changed, 62 insertions(+), 24 deletions(-)
diff --git a/configure.ac b/configure.ac
index cc
AVX2 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
Signed-off-by: Chuck Atkins
---
configure.ac | 86 +++-
1 file change
t 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
> wrote:
> >
> > Encapsulate the test for which flags are needed to get a compiler to
> > s
to build wither.
- Chuck
On Tue, Jun 28, 2016 at 2:10 PM, Chuck Atkins
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 just __AVX2__. I think it
fined
w.r.t thier availability.
Cc: Tim Rowley
Signed-off-by: Chuck Atkins
---
configure.ac | 86 +++-
1 file changed, 62 insertions(+), 24 deletions(-)
diff --git a/configure.ac b/configure.ac
index cc9bc47..92c35e8 100644
--- a/configu
fined
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
Signed-off-by: Chuck Atkins
---
configure.ac| 73 +
src/gallium/drivers/swr/Makefile.am | 4
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
Signed-off-by: Chuck Atkins
---
src/gallium/include/pipe/p_state.h
PILER. I can
update 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" wrote:
Am 28.06.2016 um 22:45 schrieb Chuck Atkins:
> This aligns the 4-element color float a
.
Reported-by: Tim Rowley
Tested-by: Tim Rowley
Signed-off-by: Chuck Atkins
Acked-by: Roland Scheidegger
---
src/gallium/include/pipe/p_state.h | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/src/gallium/include/pipe/p_state.h
b/src/gallium/include/pipe
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 co
>
> 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
u
>
> 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 b
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
Cc: 17.1
Cc: Timothy
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
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
wrote:
> On 9 June 2017 at 16:00, Chuck Atkins wrote:
> > Hi Emil,
> >
> >> Did you test the upstream versions or the distribution ones which
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 opti
>
> 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 be
: Chuck Atkins
Cc: Tim Rowley
---
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
@@ -2511,7 +2511,7 @@ if test -n "$with_gallium_drivers&q
#x27;s one of the many 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
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
there'
> 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 coinc
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
On Thu, Aug 10, 2017 at 2:04 PM, Matt Turner wrote:
> Reviewed-by: Matt Tur
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 cal
Signed-off-by: Chuck Atkins
CC: Tim Rowley
CC: Bruce Cherniak
---
src/gallium/drivers/swr/swr_loader.cpp | 41 +-
1 file changed, 25 insertions(+), 16 deletions(-)
diff --git a/src/gallium/drivers/swr/swr_loader.cpp
b/src/gallium/drivers/swr/swr_loader.cpp
filesystem.
Based on an initial implementation by Tim Rowley.
Signed-off-by: Chuck Atkins
CC: Tim Rowley
CC: Bruce Cherniak
---
configure.ac | 12 -
src/gallium/drivers/swr/Makefile.am| 48 +
src/gallium/drivers/swr/swr_loader.cpp | 95
> > +#define debug_printf(...) if(mesa_debug) { fprintf(stderr,
> __VA_ARGS__); }
>
> `do {} while(0)`
>
Forgive me but I don't understand, what you're saying here.
> Why only replace some of the printfs?
>
The fprintf's I replaced with debug_printf are informational status
messages, while the
>
> Perhaps one can split out the .cpp and build changes somehow.
>
Good idea. It's easy enough to split and without the autoconf changes the
existing behavior will still be preserved so the other two builds can still
work as they normally do, they just won't have the builtin-swr feature.
- Chuc
Hi Emil,
I'd like to try to get the builtin swr arch feature baked in. There's also
a bug related to missing propagation of static dependencies, but I can't
commit to having that one ready in time (although I'm aiming to).
- Chuck
On Tue, Jan 16, 2018 at 2:18 PM, Emil Velikov
wrote:
> Hi all,
thousands of copies
of the libs are loaded from a shared parallel filesystem.
Based on an initial implementation by Tim Rowley.
Signed-off-by: Chuck Atkins
CC: Tim Rowley
CC: Bruce Cherniak
---
configure.ac| 12 +-
src/gallium/drivers/swr/Makefile.am | 48
Signed-off-by: Chuck Atkins
CC: Tim Rowley
CC: Bruce Cherniak
---
src/gallium/drivers/swr/swr_loader.cpp | 41 +-
1 file changed, 25 insertions(+), 16 deletions(-)
diff --git a/src/gallium/drivers/swr/swr_loader.cpp
b/src/gallium/drivers/swr/swr_loader.cpp
thousands of copies
of the libs are loaded from a shared parallel filesystem.
Based on an initial implementation by Tim Rowley.
Signed-off-by: Chuck Atkins
CC: Tim Rowley
CC: Bruce Cherniak
---
src/gallium/drivers/swr/swr_loader.cpp | 94 ++
1 file changed, 60
I wasn't happy with the redundancy either but at the time just didn't see
how to refactor it more cleanly. I'll take a second pass to consolidate
and remove duplication.
- Chuck
On Tue, Jan 16, 2018 at 5:03 PM, Cherniak, Bruce
wrote:
>
> > On Jan 16, 2018, at 1:59 P
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
wrote:
> Signed-off-by: Chuck Atkins
> CC: T
> > On Jan 16, 2018, at 1:59 PM, Chuck Atkins
> wrote:
> >
> > Part 1 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 than as a separate l
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
wrote:
> I wasn't happy with the redundancy either but at the time just didn'
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
Reviewed-by: Bruce Cherniak
CC: Tim Rowley
---
src/gallium/drivers/swr
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
Reviewed-by: Bruce Cherniak
CC: Tim Rowley
---
configure.ac| 12
conditions are hit.
Signed-off-by: Chuck Atkins
Reviewed-by: Bruce Cherniak
CC: Tim Rowley
---
src/gallium/drivers/swr/swr_loader.cpp | 84 --
1 file changed, 49 insertions(+), 35 deletions(-)
diff --git a/src/gallium/drivers/swr/swr_loader.cpp
b/src/gallium
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
Reviewed-by: Bruce Cherniak
CC: Tim Rowley
---
configure.ac| 12
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 core.
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
som
Cc: mesa-sta...@lists.freedesktop.org
Cc: Bruce Cherniak
Signed-of-by: Chuck Atkins
---
configure.ac| 4 +++-
src/gallium/state_trackers/glx/xlib/Makefile.am | 1 +
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
Just saw this got merged, thanks! Any chance of it getting to stable for
the 13.1 release?
--
Chuck Atkins
Staff R&D Engineer, Scientific Computing
Kitware, Inc.
On Mon, Jan 9, 2017 at 11:10 PM, Cherniak, Bruce
wrote:
> This comes in very handy on a SLES11 (or similar) based
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 ch
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&D Engineer, Scientific Computing
Kitw
bly depending on floating
point textures in our distributed binaries without assuming shifting legal
risk
--
Chuck Atkins
Staff R&D Engineer, Scientific Computing
Kitware, Inc.
On Sat, Jun 16, 2018 at 9:10 PM Ian Romanick wrote:
> Reviewed-by: Ian Romanick
>
> I'd also
fic way so I'm not asking "how to I
address #1 and #2?" because I can certainly do that. These are just two
instances of many though in the way "auto" is dealt with. My point is
really a broader one that before meson becomes the primary build then the
behavior of "auto
Hi Emil,
I would like to revive an idea from a few years ago:
> Drop the "auto" all-together.
>
> It adds a _ton_ of complexity while making the build semi-magical/not
> as deterministic.
>
I can certainly sympathize here. I maintain a ton of build infrastructure
for a wide variety of projects a
Hi Tim, Bruce, George,
diff --git
> a/src/gallium/drivers/swr/rasterizer/jitter/functionpasses/lower_x86.cpp
> b/src/gallium/drivers/swr/rasterizer/jitter/functionpasses/lower_x86.cpp
> index 7605823c04..c58a7552a3 100644
> ---
> a/src/gallium/drivers/swr/rasterizer/jitter/functionpasses/lower_x86
Signed-off-by: Chuck Atkins
CC:
CC: Bruce Cherniak
CC: George Kyriazis
CC: Tim Rowley
---
configure.ac | 7 ++-
src/gallium/drivers/swr/rasterizer/jitter/blend_jit.cpp| 4
src/gallium/drivers/swr/rasterizer/jitter
Hi Dylan,
> xswr)
> > llvm_require_version $LLVM_REQUIRED_SWR "swr"
> > +llvm_add_default_components "swr"
> > +if test $LLVM_VERSION_MAJOR -ge 7; then
> > +llvm_add_component "ipo" "swr"
> > +llvm_add_component "ObjCARC
Hi Dylan (and others?)
SWR has some checks to try to determine which compiler option is needed to
enable a given instruction set. The way this is implemented in Meson seems
to be incorrect currently. For example, the attempt to detect the correct
compiler option to enable the AVX512 KNL instruct
Signed-off-by: Chuck Atkins
CC:
CC: Dylan Baker
CC: Bruce Cherniak
CC: Tim Rowley
---
meson.build | 37 -
1 file changed, 24 insertions(+), 13 deletions(-)
diff --git a/meson.build b/meson.build
index cbf88b5013..a7e03c29dc 100644
--- a/meson.build
+++ b
v2: Fix typo in autoconf
Signed-off-by: Chuck Atkins
CC:
CC: Bruce Cherniak
CC: Tim Rowley
---
configure.ac| 5 +
src/gallium/drivers/swr/rasterizer/jitter/blend_jit.cpp | 4
src/gallium/drivers/swr/rasterizer
Hi Dylan,
I think you could simplify this:
>
> > + if dep_llvm.found() and with_gallium_swr and
> dep_llvm.version().version_compare('>= 7')
> > +_llvm_2pass = true
> > +llvm_modules += ['ipo', 'objcarcopts']
> > + endif
> > + if _llvm_2pass
> > +dep_llvm = dependency(
> > + 'l
1 - 100 of 134 matches
Mail list logo
