We no longer need or use Visual Studio 2013.
https://ci.appveyor.com/project/jrfonseca/mesa/build/52
---
docs/install.html | 2 +-
include/c11/threads_win32.h | 12 +---
include/c99_compat.h| 4 ++--
src/util/macros.h | 4 +---
4 files changed, 5 insertions(
se {
- a = lp_build_max_simple(bld, a, b, GALLIVM_NAN_BEHAVIOR_UNDEFINED);
+ /*
+ * This must match llvm pattern for saturated unsigned sub.
+ * (lp_build_max_simple actually does the job with its current
+ * definition but do it explicitly here.)
+ * NOTE: cmp/select does sext/trunc of the mask. Does not seem to
+ * interfere with llvm's ability to recognize the pattern but seems
+ * a bit brittle.
+ */
+ LLVMValueRef no_ov = lp_build_cmp(bld, PIPE_FUNC_GREATER, a, b);
+ a = lp_build_select(bld, no_ov, a, b);
}
}
Otherwise looks great AFAICT. Thanks
Reviewed-by: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 22/08/18 18:05, Dylan Baker wrote:
v2: - fix typos in commit message
---
appveyor.yml | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/appveyor.yml b/appveyor.yml
index 15a31da9411..b26a3c624e8 100644
--- a/appveyor.yml
+++ b/appveyor.yml
@@ -34,7 +34,6 @@ branches:
The git core.autocrlf setting defaults to true (ie, all text files get
checked out as CRLF on Windows), except on Appveyor where's set to
"input" (ie, all text files get checked out with the upstream
repository's line endings, which for us typically means LF.)
And this was masking on Appveyor a re
On 17/08/18 16:08, Jose Fonseca wrote:
On 17/08/18 15:49, Mathieu Bridon wrote:
On Fri, 2018-08-17 at 15:30 +0100, Jose Fonseca wrote:
On 17/08/18 15:26, Mathieu Bridon wrote:
On Fri, 2018-08-17 at 15:08 +0100, Jose Fonseca wrote:
On 17/08/18 15:06, Jose Fonseca wrote:
On 17/08/18 14:52
On 17/08/18 15:49, Mathieu Bridon wrote:
On Fri, 2018-08-17 at 15:30 +0100, Jose Fonseca wrote:
On 17/08/18 15:26, Mathieu Bridon wrote:
On Fri, 2018-08-17 at 15:08 +0100, Jose Fonseca wrote:
On 17/08/18 15:06, Jose Fonseca wrote:
On 17/08/18 14:52, Jose Fonseca wrote:
On 17/08/18 14:30
On 17/08/18 15:26, Mathieu Bridon wrote:
On Fri, 2018-08-17 at 15:08 +0100, Jose Fonseca wrote:
On 17/08/18 15:06, Jose Fonseca wrote:
On 17/08/18 14:52, Jose Fonseca wrote:
On 17/08/18 14:30, Jose Fonseca wrote:
On 17/08/18 14:22, Mathieu Bridon wrote:
---
Jose, can you test whether this
On 17/08/18 15:06, Jose Fonseca wrote:
On 17/08/18 14:52, Jose Fonseca wrote:
On 17/08/18 14:30, Jose Fonseca wrote:
On 17/08/18 14:22, Mathieu Bridon wrote:
---
Jose, can you test whether this patch fixes your build issues?
I don't have access to a Windows machine, and I can't
On 17/08/18 14:52, Jose Fonseca wrote:
On 17/08/18 14:30, Jose Fonseca wrote:
On 17/08/18 14:22, Mathieu Bridon wrote:
---
Jose, can you test whether this patch fixes your build issues?
I don't have access to a Windows machine, and I can't reproduce your
problem on Linux.
src/ut
On 17/08/18 14:30, Jose Fonseca wrote:
On 17/08/18 14:22, Mathieu Bridon wrote:
---
Jose, can you test whether this patch fixes your build issues?
I don't have access to a Windows machine, and I can't reproduce your
problem on Linux.
src/util/xmlpool/gen_xmlpool.py | 5
On 17/08/18 14:22, Mathieu Bridon wrote:
---
Jose, can you test whether this patch fixes your build issues?
I don't have access to a Windows machine, and I can't reproduce your
problem on Linux.
src/util/xmlpool/gen_xmlpool.py | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/util
On 17/08/18 14:03, Mathieu Bridon wrote:
On Fri, 2018-08-17 at 13:29 +0100, Jose Fonseca wrote:
This change caused one of our MSVC build machines to fail with
scons: Building targets ...
Generating build\windows-x86-debug\util\xmlpool\options.h ...
Traceback (most recent call last
This change caused one of our MSVC build machines to fail with
scons: Building targets ...
Generating build\windows-x86-debug\util\xmlpool\options.h ...
Traceback (most recent call last):
File "src\util\xmlpool\gen_xmlpool.py", line 221, in
print(line, end='')
UnicodeEncodeError: 'ascii'
xit(1)
+print("yes")
+
if env['x11']:
env.Append(CPPPATH = env['X11_CPPPATH'])
Series looks good to me.
Reviewed-by: Jose Fonseca
Jose
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 14/08/18 18:34, Dylan Baker wrote:
Bugzilla:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.freedesktop.org%2Fshow_bug.cgi%3Fid%3D107565&data=02%7C01%7Cjfonseca%40vmware.com%7C2d939ac68f994873752708d6020c5ecf%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C6366986494968873
Now we do full S3TC decompression they should no longer fail.
---
src/gallium/tests/unit/u_format_test.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/src/gallium/tests/unit/u_format_test.c
b/src/gallium/tests/unit/u_format_test.c
index 6de581fd049..437cc94b757 100644
--- a/src/gallium/
raw_prim_assembler_is_required(draw, prim_info, vert_info)) {
draw_prim_assembler_run(draw, prim_info, vert_info,
Sounds good to me.
Reviewed-by: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Handle the case where there are spaces in CC env var (ie, compiler +
options.)
This updates the CC check to match what newer SCons do internally.
---
scons/gallium.py | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/scons/gallium.py b/scons/gallium.py
index 7cb2a32549..c05d86
AFAICS, we use python 2 in two places:
(1) SCons*
I suspect using Python 3 will be far from straightforward, as it will
require newer SCons versions, and all that's implied.
So I rather not embark on this yet.
(2) C code generation scripts
Python 3.5 seems to be included on our build
On 16/06/18 19:23, Matt Turner wrote:
Is LLVM-5 now your oldest supported version? I know Igalia build tests
with versions going all the way back to 3.3 before stable releases, so
they might be able to cut down the required testing.
We do plan to drop support for LLVM 3.x in the near future, bu
https://ci.appveyor.com/project/jrfonseca/mesa/build/47
---
appveyor.yml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/appveyor.yml b/appveyor.yml
index bd33e2e9554..86440f0d76a 100644
--- a/appveyor.yml
+++ b/appveyor.yml
@@ -35,13 +35,13 @@ clone_depth: 100
cache:
-
On 12/06/18 17:50, Dylan Baker wrote:
Quoting Eric Engestrom (2018-06-12 04:38:04)
On Monday, 2018-06-11 15:56:11 -0700, Dylan Baker wrote:
---
meson.build | 21 +
1 file changed, 21 insertions(+)
diff --git a/meson.build b/meson.build
index a244694fd4a..e1b3afbe688 1006
, I'm still a bit confused why this is necessary. Is that just
so the dumped output looks like it's the same as if you called
texture/buffer_subdata? Makes sense then, but in reality it still was a
transfer.
Reviewed-by: Roland Scheidegger
Am 04.06.2018 um 15:01 schrieb Jose Fonsec
The emitted buffer_subdata/texture_subdata call didn't match the
respective signatures.
v2: Actually emit buffer_subdata call.
---
.../auxiliary/driver_trace/tr_context.c | 60 +--
1 file changed, 42 insertions(+), 18 deletions(-)
diff --git a/src/gallium/auxiliary/driver_t
or textures, so did it match there?
Also, I don't really understand why it doesn't work for buffers neither,
even if some parameters don't make sense there, but if it's a transfer
this should still be correct?
Roland
Am 01.06.2018 um 20:58 schrieb Jose Fonseca:
The emitted
LLVM 5.0 requires additional Win32 libraries, and MinGW with pthreads.
---
scons/llvm.py | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/scons/llvm.py b/scons/llvm.py
index 79118be371d..a34edfb4b67 100644
--- a/scons/llvm.py
+++ b/scons/llvm.py
@@ -123,6 +123,10 @@ def
The emitted buffer_subdata/texture_subdata call didn't match the
respective signatures.
---
.../auxiliary/driver_trace/tr_context.c | 38 +--
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/src/gallium/auxiliary/driver_trace/tr_context.c
b/src/gallium/auxilia
---
src/gallium/tools/trace/dump_state.py | 31 ++-
1 file changed, 26 insertions(+), 5 deletions(-)
diff --git a/src/gallium/tools/trace/dump_state.py
b/src/gallium/tools/trace/dump_state.py
index 4531843279e..2622d130bf8 100755
--- a/src/gallium/tools/trace/dump_state.p
I don't object merging Linux into appveyor.yml somehow, but I really
don't have the time to figure out how to do it.
I also fear that Linux infrastructure might be unstable in this initial
initial period, and we end up receiving false failure notification
emails. (Even appveyor windows builds
llivm,
- bld_base->base.vec_type,
array_size,
+ unsigned array_size = bld_base->info->file_max[TGSI_FILE_IMMEDIATE] * 4
+ 4;
+ bld->imms_array = lp_build_alloca_undef(gallivm,
+
LLVMArrayType(bld_base->base.vec_type, array_size),
"imms_array");
}
Looks good to me. I suppose there was no regressions with, e.g., piglit.
Reviewed-by: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Hi Roland,
It's indeed been long time since I wrote this and I'm no longer certain
of what I intended to do, but the change looks overall.
Reviewed-by: Jose Fonseca
But is it really true rand returns 63 bits? I think it return RAND_MAX,
which was actually often 31 bits. Perhaps
interp( clipper, new_vert, t, vert, vert_prev, viewport_index
);
Series looks good to me.
Reviewed-by: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>= 0x0305) ? "[-mcpu=<-mcpu option>] " : "",
- "[-mattr=<-mattr option(s)>]",
- filename);
- }
-
if (use_mcjit) {
/* Setting the module's DataLayout to an empty string will cause the
* ExecutionEngine to copy to the DataLayout string from its target
Series looks good to me.
Reviewed-by: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
if
-#if defined(PIPE_CC_GCC)
+#if defined(PIPE_CC_GCC) && (PIPE_CC_GCC_VERSION > 404) || defined(__clang__)
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wframe-address"
frame_pointer = ((const void **)__builtin_frame_address(1));
Thanks Vin
It has been broken for a while, and not much interest from our side
in keeping it going, as most of us are using MinGW cross-compilers
anyway.
I'm not sure if there are other people interested on MSVC, so just
warn for the time being.
Also tone down the MSVC warnings, so they don't overwhelm the
Makes sense. Thanks
Reviewed-by: Jose Fonseca
On 09/03/18 00:00, Timothy Arceri wrote:
Calling __builtin_frame_address with a nonzero argument is unsafe
but is sometimes done for debugging purposes. Since this code is
part of some debug util code I'm assuming that is the case here
and
On 06/03/18 20:52, Brian Paul wrote:
Looks good. That certainly does simplify things. Two minor
suggestions below.
In any case, for both, Reviewed-by: Brian Paul
Looks great cleanup to me too. Just minor issues inline. Both are
Reviewed-by: Jose Fonseca
On 03/06/2018 01:34 PM, srol
Brian Paul
I also admit that somehow reg & 31 made me pause, but reg % 32 seems
obviously right.
Reviewed-by: Jose Fonseca
Jose
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 27/02/18 02:38, srol...@vmware.com wrote:
From: Roland Scheidegger
Some state trackers require 128.
(There are no plans to increase PIPE_MAX_SAMPLERS too, since with gl
state tracker it's unlikely more than 32 will be needed, if you need
more use bindless.)
---
src/gallium/include/pipe/p_s
struct pipe_resource *tex = view->texture;
Series LGTM.
Reviewed-by: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_views[shader_stage][i] = views[i];
- for (i = num; i < PIPE_MAX_SHADER_SAMPLER_VIEWS; ++i)
+ for (i = num; i < draw->num_sampler_views[shader_stage]; ++i)
draw->sampler_views[shader_stage][i] = NULL;
draw->num_sampler_views[shader_stage] = num;
Revi
The MSVC version we (at VMware) primarily care about from now on is
2015.
We can drop support for building with 2013 in a future commit. I'm not
aware of significant changes in C99/C11 support from MSVC 2013 to 2015,
but there's no point in continuing supporting old MSVC versions when
nobody care
-231,6 +278,7 @@ tgsi_transform_shader(const struct tgsi_token *tokens_in,
assert( 0 );
}
}
+ assert(call_stack == 0);
tgsi_parse_free (&parse);
LGTM. Thanks.
Reviewed-by: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
oblem surfaces.
Reviewed-by: Jose Fonseca
On 13/02/18 04:10, srol...@vmware.com wrote:
From: Roland Scheidegger
Shaders coming from dx10 state trackers have a RET before the END.
And the epilog needs to be placed before the RET (otherwise it will
get ignored).
Hence figure out if a RET is in mai
b_state(MAYBE_UNUSED struct blitter_context_priv *ctx)
{
- assert(ctx->base.saved_fb_state.nr_cbufs != ~0u);
+ assert(ctx->base.saved_fb_state.nr_cbufs != (ubyte) ~0);
}
static void blitter_disable_render_cond(struct blitter_context_priv *ctx)
Thanks.
t_tex_shader_xrbias(struct pipe_context *pipe,
+ unsigned tex_target);
+
extern void *
util_make_fragment_tex_shader_writemask(struct pipe_context *pipe,
unsigned tex_target,
LGTM.
Reviwed-by: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Looks great.
Reviewed-by: Jose Fonseca
On 25/01/18 03:33, srol...@vmware.com wrote:
From: Roland Scheidegger
We are not allowed to modify the incoming coords values, or things may
crash (as we may be inside a llvm conditional and the values may be used
in another branch).
I recently broke
On 22/01/18 21:04, Samuel Thibault wrote:
Hello,
Jose Fonseca, on lun. 15 janv. 2018 12:29:39 +, wrote:
On 13/01/18 11:33, Samuel Thibault wrote:
pthread_setname_np was added in glibc 2.12 for the Linux port only, other
ports do not necessarily have it.
---
src/util/u_thread.h | 3
On 22/01/18 15:44, Emil Velikov wrote:
On 22 January 2018 at 15:13, Jose Fonseca wrote:
Courtesy of clang static analyzer.
I was hunting for potential sources of memory corruption using Mesa with
a GL trace, and happened to find this (unrelated) issue.
---
src/gallium/drivers/svga
I suspect it's an infrastructure problem. I appeared frequently a while
back, then went away, now's comming again.
I think the consensus is to move this jobs out of fdo into
https://github.com/mesa3d but I got no reply from Daniel Stone, so I'm
not sure how to move that forward.
Jose
On 19
Courtesy of clang static analyzer.
I was hunting for potential sources of memory corruption using Mesa with
a GL trace, and happened to find this (unrelated) issue.
---
src/gallium/drivers/svga/svga_context.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/svga/svga_contex
)((int)(DRAW_GET_IDX(elts, elt_idx)) + elt_bias);
/* Take care for DRAW_MAX_FETCH_IDX (since cache is initialized to -1). */
if (elt_idx == DRAW_MAX_FETCH_IDX && !vsplit->cache.has_max_fetch) {
unsigned hash = elt_idx % MAP_SIZE;
Reviewed-by: Jose Fonseca
vsplit->cache.fetches[hash] = 0;
vsplit->cache.has_max_fetch = TRUE;
Looks good to me. This code is indeed subtle.
Reviewed-by: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
\
- (__GLIBC__ >= 3 || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 12))
+ (__GLIBC__ >= 3 || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 12)) && \
+ defined(__linux__)
pthread_setname_np(pthread_self(), name);
# en
#endif
#ifdef __cplusplus
Reviewed-by: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
oord = lp_build_sub(coord_bld, coord, half);
Series LGTM.
Reviewed-by: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
border all resulting coords are safe).
+ */
coord = lp_build_sub(coord_bld, coord, half);
/* convert to int, compute lerp weight */
@@ -652,7 +748,7 @@ lp_build_sample_wrap_nearest(struct lp_build_sample_context
*bld,
coord = lp_build_add(coord_b
On 24/11/17 14:25, Emil Velikov wrote:
From: Emil Velikov
Analogous to the other build systems.
Cc: Jose Fonseca
Cc: Brian Paul
Signed-off-by: Emil Velikov
---
scons/gallium.py | 1 +
1 file changed, 1 insertion(+)
diff --git a/scons/gallium.py b/scons/gallium.py
index ef3b2ee81ae
ermh, dst_termh);
+
+ /*
+ * XXX pack2_native is not ok because the values have to be in dst
+ * range. We need native pack though for the correct order on avx2.
+ * Will break on everything not implementing clamping pack intrinsics
+ * (i.e. everything but s
On 16/11/17 15:56, Eric Engestrom wrote:
On Thursday, 2017-11-16 14:20:03 +, Jose Fonseca wrote:
On 16/11/17 14:08, Jose Fonseca wrote:
On 15/11/17 12:20, Eric Engestrom wrote:
On Wednesday, 2017-11-15 10:35:04 +, Jose Fonseca wrote:
I could post a remark on AppVeyor's forums, b
On 16/11/17 14:08, Jose Fonseca wrote:
On 15/11/17 12:20, Eric Engestrom wrote:
On Wednesday, 2017-11-15 10:35:04 +, Jose Fonseca wrote:
I could post a remark on AppVeyor's forums, but it sounds from the
logs the issue could be on our (freedesktop.org's) side.
I've reconf
On 15/11/17 12:20, Eric Engestrom wrote:
On Wednesday, 2017-11-15 10:35:04 +, Jose Fonseca wrote:
I could post a remark on AppVeyor's forums, but it sounds from the
logs the issue could be on our (freedesktop.org's) side.
I've reconfigured AppVeyor to use
https://anongit.
I could post a remark on AppVeyor's forums, but it sounds from the logs the
issue could be on our (freedesktop.org's) side.
I've reconfigured AppVeyor to use
https://anongit.freedesktop.org/git/mesa/mesa.git/ instead of
git://anongit.freedesktop.org/mesa/mesa . Perhaps fewer things can go wro
On 11/11/17 01:37, Jordan Justen wrote:
On 2017-11-09 19:40:40, Jordan Justen wrote:
On 2017-11-09 08:07:57, Jose Fonseca wrote:
On 09/11/17 13:19, Emil Velikov wrote:
On 9 November 2017 at 06:42, Jordan Justen wrote:
Signed-off-by: Jordan Justen
Currently zlib is a dependency for
On 10/11/17 03:40, Jordan Justen wrote:
On 2017-11-09 08:07:57, Jose Fonseca wrote:
On 09/11/17 13:19, Emil Velikov wrote:
Hi Jordan,
On 9 November 2017 at 06:42, Jordan Justen wrote:
Signed-off-by: Jordan Justen
---
src/util/Makefile.sources | 2 +
src/util/meson.build | 2
On 09/11/17 13:19, Emil Velikov wrote:
Hi Jordan,
On 9 November 2017 at 06:42, Jordan Justen wrote:
Signed-off-by: Jordan Justen
---
src/util/Makefile.sources | 2 +
src/util/meson.build | 2 +
src/util/program_binary.c | 322 ++
src/u
On 26/10/17 13:55, Jose Fonseca wrote:
On 23/10/17 20:15, Emil Velikov wrote:
Hi Nicolai,
On 22 October 2017 at 20:07, Nicolai Hähnle wrote:
From: Nicolai Hähnle
C11 threads were changed to use struct timespec instead of xtime, and
thrd_sleep got a second argument.
As xtime was replaced
f odd bits in the code.
See http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1554.htm and
http://en.cppreference.com/w/c/thread/{thrd_sleep,cnd_timedwait,mtx_timedlock}
Note that cnd_timedwait is spec'd to be relative to TIME_UTC / CLOCK_REALTIME.
Cc: Jose Fonseca
---
include/c11
On 13/10/17 18:44, Jason Ekstrand wrote:
ssize_t is a GNU extension and is not available on Windows or MacOS.
Instead, we use intptr_t which should be effectively equivalent and is
part of the C standard. This should fix the Windows and Mac OS builds.
Cc: Jose Fonseca
Cc: Vinson Lee
Fixes
Per https://bugs.freedesktop.org/show_bug.cgi?id=103253 it's not just
MSVC. So I'd really recommend sticking to one of the standard C types:
intptr_t or int64_t.
Jose
On 13/10/17 10:41, Jose Fonseca wrote:
SSIZE_T is included on the headers. We include it in most
places, but not
SSIZE_T is included on the headers. We include it in most
places, but not necessary all. It brings a lot of baggage, so I don't
recommend including it just for a ssize_t defitinion.
Instead I'd recommend replacing ssize_t in our code with plain standard
intptr_t.
If you really rather use
On 11/10/17 16:50, Tim Rowley wrote:
Increase the max allowed vector size from 256 to 512.
No piglit llvmpipe regressions running on avx2.
Cc: Dave Airlie
Cc: Jose Fonseca
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c | 14 +++---
src/gallium/auxiliary/gallivm/lp_bld_type.h
On 10/10/17 16:31, Kyriazis, George wrote:
Hello…
Piglit on windows prints out a message saying “Timeout are not implemented on
Windows.”. These timeouts are the test timeouts in case a test hangs.
What do people do when running piglit on windows and they hit a timeout? I
would imagine ther
'--short=10',
+'HEAD',
+], stderr=open(os.devnull, 'w')).decode("ascii")
+except:
+ # don't print anything if it fails
+git_sha1 = None
+return git_sha1
+
+
+git_sha1 = get_git_envvar()
+if not git_sha1:
+git_sha
On 29/09/17 12:17, Nicolai Hähnle wrote:
On 28.09.2017 20:02, Roland Scheidegger wrote:
Am 28.09.2017 um 18:19 schrieb Jose Fonseca:
On 28/09/17 17:16, Roland Scheidegger wrote:
Am 28.09.2017 um 17:53 schrieb Jose Fonseca:
On 28/09/17 16:29, Roland Scheidegger wrote:
Am 28.09.2017 um 16:12
On 28/09/17 17:16, Roland Scheidegger wrote:
Am 28.09.2017 um 17:53 schrieb Jose Fonseca:
On 28/09/17 16:29, Roland Scheidegger wrote:
Am 28.09.2017 um 16:12 schrieb Jose Fonseca:
On 27/09/17 15:07, Roland Scheidegger wrote:
Am 27.09.2017 um 09:13 schrieb Olivier Lauffenburger:
Software
On 28/09/17 16:29, Roland Scheidegger wrote:
Am 28.09.2017 um 16:12 schrieb Jose Fonseca:
On 27/09/17 15:07, Roland Scheidegger wrote:
Am 27.09.2017 um 09:13 schrieb Olivier Lauffenburger:
Software rasterizer and LLVM contain code to enable clipping as soon as
a vertex shader writes to
On 27/09/17 15:07, Roland Scheidegger wrote:
Am 27.09.2017 um 09:13 schrieb Olivier Lauffenburger:
Software rasterizer and LLVM contain code to enable clipping as soon as
a vertex shader writes to gl_ClipDistance, even if the corresponding
clip planes are disabled.
GLSL specification states that
.h
+++ b/src/gallium/include/pipe/p_shader_tokens.h
@@ -607,7 +607,9 @@ struct tgsi_property_data {
#define TGSI_OPCODE_DDIV248
-#define TGSI_OPCODE_LAST249
+#define TGSI_OPCODE_LOD 249
+
+#define TGSI_OPCODE_LAST250
/**
* Opcode
On 26/09/17 12:20, Ilia Mirkin wrote:
On Tue, Sep 26, 2017 at 7:07 AM, Jose Fonseca wrote:
On 25/09/17 14:30, Eric Engestrom wrote:
I pushed the rest of the series.
See below for discussion on this patch.
On Wednesday, 2017-09-20 17:05:21 +, Jose Fonseca wrote:
On 19/09/17 15:14
On 25/09/17 14:30, Eric Engestrom wrote:
I pushed the rest of the series.
See below for discussion on this patch.
On Wednesday, 2017-09-20 17:05:21 +, Jose Fonseca wrote:
On 19/09/17 15:14, Eric Engestrom wrote:
Signed-off-by: Eric Engestrom
---
scons/custom.py | 2 +-
1 file
On 22/09/17 19:38, Dylan Baker wrote:
Quoting Jose Fonseca (2017-09-22 11:10:34)
On 22/09/17 18:47, Nirbheek Chauhan wrote:
On Fri, Sep 22, 2017 at 10:19 PM, Jose Fonseca wrote:
cmake provides a generic mechanism to set any variable, either from a
command line -DFOO=boo, or via cache files
On 22/09/17 18:47, Nirbheek Chauhan wrote:
On Fri, Sep 22, 2017 at 10:19 PM, Jose Fonseca wrote:
cmake provides a generic mechanism to set any variable, either from a
command line -DFOO=boo, or via cache files. But meson didn't provide such
standard mechanism AFAICT.
In Meson you
On 21/09/17 09:56, Nirbheek Chauhan wrote:
On Thu, Sep 21, 2017 at 1:53 PM, Jose Fonseca wrote:
On 12/04/17 18:57, Nirbheek Chauhan wrote:
Hi Jose,
On Wed, Apr 12, 2017 at 11:08 PM, Jose Fonseca
wrote:
One newbie question: what's your workflow to update a wrap patch? Can we
prot
On 21/09/17 01:20, Eric Anholt wrote:
Dylan Baker writes:
Results
autotools : sh -c 535.34s user 30.33s system 310% cpu 3:02.05 total
meson : sh -c 136.58s user 11.98s system 372% cpu 39.895 total
I just want to point at these numbers again. meson is so transformative
for your normal
On 12/04/17 18:57, Nirbheek Chauhan wrote:
Hi Jose,
On Wed, Apr 12, 2017 at 11:08 PM, Jose Fonseca wrote:
One newbie question: what's your workflow to update a wrap patch? Can we
prototype changes locally without tarballing the patch?
Any changes you make in subproject directories wi
this won't give the wrong results for unicode strings,
but at any rate, I don't think that should ever happen in practice.
So,
Reviewed-by: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/m
-symbols = sym_table.keys()
+symbols = list(sym_table.keys())
This one needs to stay.
# convert the symbol table to source lists
src_lists = {}
Either way, this patch is
Reviewed-by: Jose Fonseca
__
rning: swr requires LLVM >= 3.9: not building swr"
+print("warning: swr requires LLVM >= 3.9: not building swr")
env['swr'] = False
Return()
@@ -28,7 +28,7 @@ if env['platform'] == 'windows':
else:
llvm_config = os.environ.get('LLVM_CONFIG', 'llvm-config')
llvm_includedir = env.backtick('%s --includedir' % llvm_config).rstrip()
-print "llvm include dir %s" % llvm_includedir
+print("llvm include dir %s" % llvm_includedir)
if not env['msvc'] :
env.Append(CCFLAGS = [
diff --git a/src/gallium/targets/dri/SConscript
b/src/gallium/targets/dri/SConscript
index d7a8cbdca5d7545dc324..f5c2818d04f3c6773dd6 100644
--- a/src/gallium/targets/dri/SConscript
+++ b/src/gallium/targets/dri/SConscript
@@ -3,7 +3,7 @@ Import('*')
env = drienv.Clone()
if env['suncc']:
-print 'warning: not building dri-vmwgfx'
+print('warning: not building dri-vmwgfx')
Return()
env.Append(CPPPATH = [
Thanks for doing this.
This patch is
Reviewed-by: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
-git a/src/gallium/drivers/llvmpipe/lp_screen.c
b/src/gallium/drivers/llvmpipe/lp_screen.c
index dba7ae3..fcad5da 100644
--- a/src/gallium/drivers/llvmpipe/lp_screen.c
+++ b/src/gallium/drivers/llvmpipe/lp_screen.c
@@ -252,7 +252,6 @@ llvmpipe_get_param(struct pipe_screen *screen, enum
pipe_cap param)
case PIPE_CAP_MAX_TEXTURE_GATHER_COMPONENTS:
return 4;
case PIPE_CAP_TEXTURE_GATHER_SM5:
- case PIPE_CAP_TEXTURE_QUERY_LOD:
case PIPE_CAP_SAMPLE_SHADING:
case PIPE_CAP_TEXTURE_GATHER_OFFSETS:
return 0;
@@ -265,6 +264,7 @@ llvmpipe_get_param(struct pipe_screen *screen, enum
pipe_cap param)
return 1;
case PIPE_CAP_FAKE_SW_MSAA:
return 1;
+ case PIPE_CAP_TEXTURE_QUERY_LOD:
case PIPE_CAP_CONDITIONAL_RENDER_INVERTED:
case PIPE_CAP_TGSI_ARRAY_COMPONENTS:
case PIPE_CAP_DOUBLES:
LGTM.
Reviewed-by: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_VARIANTS / 16 : 0;
if (variants_to_cull ||
lp->nr_fs_instrs >= LP_MAX_SHADER_INSTRUCTIONS) {
struct pipe_context *pipe = &lp->pipe;
+ if (gallivm_debug & GALLIVM_DEBUG_PERF) {
+debug_printf("Evicting FS: %u fs variants,\t%u total variants,"
+ "\t%u instrs,\t%u instrs/variant\n",
+ shader->variants_cached,
+ lp->nr_fs_variants, lp->nr_fs_instrs,
+ lp->nr_fs_instrs / lp->nr_fs_variants);
+ }
+
/*
* XXX: we need to flush the context until we have some sort of
* reference counting in fragment shaders as they may still be binned
Series is
Reviewed-by: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
flt_depth_vec, offsets[2],
bld->static_texture_state->pot_depth,
bld->static_sampler_state->wrap_r,
Otherwise looks good.
Reviewed-by: Jose Fonseca
AMPLER_LOD_ZERO;
@@ -5687,7 +5690,7 @@ exec_instruction(
break;
case TGSI_OPCODE_GATHER4:
- assert(0);
+ exec_sample(mach, inst, TEX_MODIFIER_GATHER, FALSE);
break;
case TGSI_OPCODE_SVIEWINFO:
LGTM.
Reviewed-by: Jose Fonseca
__
hich use a different
- * number of max shader variants.
*/
-#define LP_MAX_SHADER_INSTRUCTIONS MAX2(256*1024, 512*LP_MAX_SHADER_VARIANTS)
+#define LP_MAX_SHADER_INSTRUCTIONS (2048 * LP_MAX_SHADER_VARIANTS)
/**
* Max number of setup variants that will be kept around.
Revie
b_l.cpp
Vinson, Jose: are you guys OK with the basic check I added in scons, or
do you know of a better way to check this?
These function checks are run every time, so can add some overhead, but
looks ok for now. We can can try to improve if the itch is too great.
Reviewed-by: Jose
sched_param = {0};
/* The nice() function can only set a maximum of 19.
Reviewed-by: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 22/08/17 12:28, Marek Olšák wrote:
On Tue, Aug 22, 2017 at 1:10 PM, Jose Fonseca wrote:
On 20/08/17 01:49, Marek Olšák wrote:
From: Marek Olšák
use COS+SIN instead.
I don't know if any existing gallium driver leverages that, but it's a basic
trigonometric principle th
On 20/08/17 01:49, Marek Olšák wrote:
From: Marek Olšák
use COS+SIN instead.
I don't know if any existing gallium driver leverages that, but it's a
basic trigonometric principle that one can easily extract the sin from
cos or vice-versa. It requires some extra care for getting the right
s
On 18/08/17 08:23, Frank Richter wrote:
Hi,
On 17.08.2017 02:34, Brian Paul wrote:
BTW, I wonder if we would win by using lldiv(). Because this is often
use for performance measurements, so these extra division might add some
impact.
Frank, do you want to look into that? In the mean time, I'
erity of precision loss.
+*/
+ secs = counter.QuadPart / frequency.QuadPart;
+ nanosecs = (counter.QuadPart % frequency.QuadPart) * INT64_C(10)
+ / frequency.QuadPart;
+ return secs*INT64_C(10) + nanosecs;
#else
Series looks great.
Thanks!
Reviewed-by: Jose
101 - 200 of 2347 matches
Mail list logo
