>
> My 2 cents, which take with a grain of salt given that I'm an "every once
in a while" contributor...
This seems wrong to me from a point of keeping up the integrity of the
> project.
I understand the sentiment of project professionalism, but also keep in
mind that not every contributor is
Can we use Gitlab's GitHub import feature?
https://gitlab.freedesktop.org/help/user/project/import/github.md
I haven't used it before but it looks like it will migrate everything, i.e.
repo, issues, prs, etc.
- Chuck
On Wed, Sep 4, 2019, 9:57 AM Kyle Brenneman wrote:
> On 9/1/19 2:46 PM,
eed to add
> the Cc: stable tag or the Fixes: tag to the commit message of all commits
> you wanna nominate.
>
> Mare
>
> On Mon, May 6, 2019 at 12:12 PM Chuck Atkins
> wrote:
>
>> When doing an MR via GitLab, is adding the Cc: mesa-stable item enough to
>> nomi
the fix in the next stable release, but it's really a broader
workflow question of how stable is dealt with while both the MR and ML
processes are active.
--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
___
mesa-dev mailing
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 Engineer, Scientific Computing
Kitware, Inc.
(518) 881-1183
part does
an okay job, the meson build does not.
------
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
On Fri, Nov 23, 2018 at 8:46 PM Marek Olšák wrote:
> On Fri, Nov 16, 2018 at 11:05 PM Dylan Baker wrote:
>
>> Quoting Dylan Baker (2018-09-17 09:4
Tested-by: Chuck Atkins
On Tue, Oct 16, 2018 at 8:51 AM Cherniak, Bruce
wrote:
> Reviewed-by: Bruce Cherniak
>
> > On Oct 15, 2018, at 9:53 AM, Alok Hota wrote:
> >
> > Converted from x86 VFMADDPS intrinsic to generic LLVM intrinsic, and
> > removed createIn
ker wrote:
> > > Quoting Chuck Atkins (2018-09-24 13:24:29)
> > > > Hi Dylan,
> > > >
> > > >
> > > > I think you could simplify this:
> > > >
> > > > > + if dep_llvm.found() and with_gallium_swr and
&g
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(
> > +
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
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
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
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
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 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
> ---
>
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
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" should create a successful configure out of the box
without additi
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
>
> > If there's a better way forward for having a minimal-dependency
> > software-only implementation, I'd certainly be willing to try it. At the
> > moment though, gallium-xlib-glx is our path for that.
> >
> I was merely mentioning that the xlib-glx are in worse shape than the dri
> one.
>
>
>
> On 22 February 2018 at 14:33, Chuck Atkins <chuck.atk...@kitware.com>
> wrote:
> > This fixes a segfault exposed by a29d63ecf7 which occurs when swr is
> > used on an unsupported architecture.
> >
> > v2: re-work to place logic in xmesa_init_disp
This fixes a segfault exposed by a29d63ecf7 which occurs when swr is
used on an unsupported architecture.
v2: re-work to place logic in xmesa_init_display
Signed-off-by: Chuck Atkins <chuck.atk...@kitware.com>
Cc: mesa-sta...@lists.freedesktop.org
Cc: George Kyriazis <george.kyria...@
> Thanks,
>
> George
>
> > On Feb 21, 2018, at 8: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 architecture.
> >
>
>
> 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
> > - 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
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
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
>
> 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 "
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
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
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
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
>
> > +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
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
> 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
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
Hi Emil,
Fixes: a4be2bcee2f ("swr: allow a single swr architecture to be builtin")
>
It doesn't fix anything that was broken from that commit. The issues with
error handling were already present before then, it's just that the changes
in a4be2bcee2f were substantial so this commit works off the
and remove unnecessary "PUBLIC"
v3: Fix typo in commit message.
Signed-off-by: Chuck Atkins <chuck.atk...@kitware.com>
Reviewed-by: Emil Velikov <emil.veli...@collabora.com>
Cc: Bruce Cherniak <bruce.chern...@intel.com>
Cc: Tim Rowley <timothy.o.row...@intel.co
and remove unnecessary "PUBLIC"
Signed-off-by: Chuck Atkins <chuck.atk...@kitware.com>
Reviewed-by: Emil Velikov <emil.veli...@collabora.com>
Cc: Bruce Cherniak <bruce.chern...@intel.com>
Cc: Tim Rowley <timothy.o.row...@intel.com>
---
src/galliu
Hi Emil,
Please include your follow-up reply/context as commit message.
>
Will do.
> +// cleanup for failed screen creation
> > +PUBLIC void swr_destroy_screen_internal(struct swr_screen **screen);
>
> I'm fairly sure you don't need to make this function public. It's used
> within the same
For context, without this, the library handle from dlopen never get's
closed, even under successful operation, and the swr_screen created never
get's freed on error. Also error conditions resulted in exit() rather than
NULL return.
- Chuck
On Mon, Jan 22, 2018 at 10:12 AM, Chuck Atkins
Signed-off-by: Chuck Atkins <chuck.atk...@kitware.com>
---
src/gallium/drivers/swr/swr_loader.cpp | 100 +
src/gallium/drivers/swr/swr_public.h | 6 +-
src/gallium/drivers/swr/swr_screen.cpp | 26 +++--
src/gallium/drivers/swr/swr_screen.h |
Signed-off-by: Chuck Atkins <chuck.atk...@kitware.com>
---
src/gallium/drivers/swr/swr_loader.cpp | 100 +
src/gallium/drivers/swr/swr_public.h | 6 +-
src/gallium/drivers/swr/swr_screen.cpp | 26 +++--
src/gallium/drivers/swr/swr_screen.h |
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
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
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
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
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
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
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
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
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
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
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(-)
of 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 <chuck.atk...@kitware.com>
CC: Tim Rowley <timothy.o.row...@intel.com>
CC: Bruce Cherniak <bruce.chern...@intel.com>
---
src/g
of 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 <chuck.atk...@kitware.com>
CC: Tim Rowley <timothy.o.row...@intel.com>
CC: Bruce Cherniak <bruce.chern...@intel.com>
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
>
> 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.
-
> > +#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
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
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(-)
>
> 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
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
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:
> 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
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
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
-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
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,
> >
> >>
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
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.
>
> 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
>
> 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
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
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
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
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
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
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
> 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
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
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
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
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
>
> > +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
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
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 +
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
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
>&
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
>
> 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
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:
> &
.
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
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
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 <
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
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
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
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
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
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
1 - 100 of 134 matches
Mail list logo