On 28/02/15 00:24, Rob Clark wrote:
On Fri, Feb 27, 2015 at 5:05 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
- src/gallium/drivers/rbug: -- do people use it? does it work? it
predates apitrace GL + GUI, which sort of enables a lot of the same
things, but without the issue of having to hit
On 27/02/15 15:16, Jose Fonseca wrote:
As we're gaining momentum cleanup Mesa code, I think it would help if we
also removed some stale components.
What do people feel about removing:
- src/mesa/drivers/windows/gdi -- the old SW rasterizer for Windows -- I
haven't used in a very long time
v2:
- Single statement, by using memset return value as suggested by Ian
Romanick.
- No internal declaration, as suggested by Jason Ekstrand.
- Move macros to a header.
---
src/glsl/nir/nir_from_ssa.c | 23 ++-
src/glsl/nir/nir_live_variables.c| 4 +--
On 02/03/15 20:03, Jason Ekstrand wrote:
On Mon, Mar 2, 2015 at 8:02 AM, Jose Fonseca jfons...@vmware.com
mailto:jfons...@vmware.com wrote:
On 27/02/15 16:15, Brian Paul wrote:
On 02/27/2015 09:10 AM, Ian Romanick wrote:
On 02/26/2015 10:07 AM, Brian Paul wrote
On 03/03/15 15:57, Brian Paul wrote:
We're using both of these in Mesa/gallium. It would be nice to
consistently just use C99's __func__ everywhere. This would be any easy
task for someone looking for something simple to do.
We could then get rid of this (broken) chunk seen in both compiler.h
On 03/03/15 12:31, Jose Fonseca wrote:
On 27/02/15 15:16, Jose Fonseca wrote:
As we're gaining momentum cleanup Mesa code, I think it would help if we
also removed some stale components.
What do people feel about removing:
- src/mesa/drivers/windows/gdi -- the old SW rasterizer for Windows
On 03/03/15 20:56, Jan Vesely wrote:
On Tue, 2015-03-03 at 10:07 -0700, Brian Paul wrote:
On 03/03/2015 09:56 AM, Jose Fonseca wrote:
On 03/03/15 15:57, Brian Paul wrote:
We're using both of these in Mesa/gallium. It would be nice to
consistently just use C99's __func__ everywhere
On 03/03/15 18:39, Emil Velikov wrote:
On 3 March 2015 at 17:16, Jose Fonseca jfons...@vmware.com wrote:
...
I've prototyped this in
https://urldefense.proofpoint.com/v2/url?u=http-3A__cgit.freedesktop.org_-7Ejrfonseca_mesa_log_-3Fh-3Dremove-2Dst-2Degld=AwIBaQc
On 03/03/15 11:59, Emil Velikov wrote:
On 3 March 2015 at 09:36, Jose Fonseca jfons...@vmware.com wrote:
On 28/02/15 00:24, Rob Clark wrote:
On Fri, Feb 27, 2015 at 5:05 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
- src/gallium/drivers/rbug: -- do people use it? does it work
On 02/03/15 19:42, Kenneth Graunke wrote:
On Monday, March 02, 2015 03:24:18 PM Jose Fonseca wrote:
On 28/02/15 00:25, Kenneth Graunke wrote:
On Friday, February 27, 2015 09:58:51 PM Jose Fonseca wrote:
Sorry, this didn't pop up when I built it here. And I'm afraid I won't have
time to look
On 27/02/15 15:59, Ian Romanick wrote:
I like the idea as it should prevent future thrash. There are a couple
comments below.
On 02/26/2015 08:51 AM, Jose Fonseca wrote:
The main objective of this change is to enable Linux developers to use
more of C99 throughout Mesa, with confidence
On 27/02/15 22:50, Jason Ekstrand wrote:
On Fri, Feb 27, 2015 at 6:04 AM, Jose Fonseca jfons...@vmware.com
mailto:jfons...@vmware.com wrote:
On 26/02/15 18:07, Brian Paul wrote:
On 02/26/2015 09:51 AM, Jose Fonseca wrote:
This is to enable the code to build
On 28/02/15 00:25, Kenneth Graunke wrote:
On Friday, February 27, 2015 09:58:51 PM Jose Fonseca wrote:
Sorry, this didn't pop up when I built it here. And I'm afraid I won't have
time to look into this today, and possibly the weekend.
If there's not an obvious fix feel free to push a commit
On 27/02/15 16:15, Brian Paul wrote:
On 02/27/2015 09:10 AM, Ian Romanick wrote:
On 02/26/2015 10:07 AM, Brian Paul wrote:
On 02/26/2015 09:51 AM, Jose Fonseca wrote:
This is to enable the code to build with -Werror=vla in the short term,
and enable the code to build with MSVC2013 soon after
On 26/02/15 18:07, Brian Paul wrote:
On 02/26/2015 09:51 AM, Jose Fonseca wrote:
This is to enable the code to build with -Werror=vla in the short term,
and enable the code to build with MSVC2013 soon after.
---
include/c99_alloca.h | 45
It's unmaintained, and most likely broken: I use trace driver every now
and then, and everytime I do I need to fix it up.
It's also unused: identity_screen_create is never called.
Above all, it's dead weight: if identity driver had the infrastructure
for other pass-through drivers (like trace
As we're gaining momentum cleanup Mesa code, I think it would help if we
also removed some stale components.
What do people feel about removing:
- src/mesa/drivers/windows/gdi -- the old SW rasterizer for Windows -- I
haven't used in a very long time, and given that the old SW rasterizer
is
can.
Jose
From: Tom Stellard t...@stellard.net
Sent: 27 February 2015 16:21
To: Jose Fonseca
Cc: mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH 2/2] configure: Leverage gcc warn options to
enable safe use of C99 features where possible.
Hi
I think this is fine now.
We need to update SCons to be less pedantic about the
-Wdeclaration-after-statement / -Wpointer-arith this on a per-directory-basis,
like my recent configure.ac change.
Jose
From: mesa-dev
Thanks!
From: mesa-dev mesa-dev-boun...@lists.freedesktop.org on behalf of Matt
Turner matts...@gmail.com
Sent: 27 February 2015 19:48
To: mesa-dev@lists.freedesktop.org
Subject: [Mesa-dev] [PATCH] mapi: Don't rely on GNU void pointer arithmetic.
Commit
On 26/02/15 00:06, Brian Paul wrote:
Just to keep things consistent.
---
src/gallium/include/pipe/p_defines.h | 66
1 file changed, 36 insertions(+), 30 deletions(-)
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
This is to enable the code to build with -Werror=vla in the short term,
and enable the code to build with MSVC2013 soon after.
---
include/c99_alloca.h | 45
src/glsl/nir/nir_from_ssa.c | 19 +++
On 26/02/15 15:27, Emil Velikov wrote:
On 26/02/15 12:09, Jose Fonseca wrote:
MSVC 2008 (shipped with Windows SDK 7.0.7600) is the oldest we
need to support. At least on llvmpipe, gallium/auxiliary, and util
modules. For the remaining modules (particular all OpenGL specific
code) can be built
The main objective of this change is to enable Linux developers to use
more of C99 throughout Mesa, with confidence that the portions that need
to be built with MSVC -- and only those portions --, stay portable.
This is achieved by using the appropriate -Werror= options only on the
places they
On 26/02/15 15:39, Brian Paul wrote:
On 02/26/2015 05:07 AM, Jose Fonseca wrote:
On 26/02/15 09:19, Erik Faye-Lund wrote:
On Thu, Feb 26, 2015 at 10:10 AM, Erik Faye-Lund kusmab...@gmail.com
wrote:
On Thu, Feb 26, 2015 at 4:24 AM, Matt Turner matts...@gmail.com
wrote:
On Wed, Feb 25, 2015
.
Reviewed-by: Eric Anholt e...@anholt.net
Reviewed-by: Jose Fonseca jfons...@vmware.com
which switched over a bunch of preprocessor checks around __builtin*
calls to use the macros defined by autotools.
So I think cleaning it up to use __builtin_ffs* first #ifdef
HAVE___BUILTIN_* can go
On 26/02/15 13:42, Jose Fonseca wrote:
On 26/02/15 03:55, Jonathan Gray wrote:
On Wed, Feb 25, 2015 at 07:09:26PM -0800, Matt Turner wrote:
On Wed, Feb 25, 2015 at 7:03 PM, Jonathan Gray j...@jsg.id.au wrote:
On Wed, Feb 25, 2015 at 06:53:14PM -0800, Matt Turner wrote:
On Wed, Feb 25, 2015
+/* This is to ensure that we get M_PI, etc. definitions */
+#if defined(_MSC_VER) !defined(_USE_MATH_DEFINES)
+#error _USE_MATH_DEFINES define required when building with MSVC
+#endif
Thanks. It could be moved inside the `#if defined(_MSC_VER)` too.
Either way
Reviewed-by: Jose Fonseca jfons
On 26/02/15 09:19, Erik Faye-Lund wrote:
On Thu, Feb 26, 2015 at 10:10 AM, Erik Faye-Lund kusmab...@gmail.com wrote:
On Thu, Feb 26, 2015 at 4:24 AM, Matt Turner matts...@gmail.com wrote:
On Wed, Feb 25, 2015 at 5:29 PM, Brian Paul bri...@vmware.com wrote:
Should be defined in math.h. If
Series looks good AFAICT. Nice seeing all these cleanups!
Reviewed-by: Jose Fonseca jfons...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
MSVC 2008 (shipped with Windows SDK 7.0.7600) is the oldest we
need to support. At least on llvmpipe, gallium/auxiliary, and util
modules. For the remaining modules (particular all OpenGL specific
code) can be built with MSVC 2013.
---
include/c99_compat.h| 11 +++---
On 24/02/15 23:30, Brian Paul wrote:
---
src/mesa/main/imports.h | 8
src/mesa/main/light.c| 2 +-
src/mesa/math/m_matrix.c | 4 ++--
3 files changed, 3 insertions(+), 11 deletions(-)
diff --git a/src/mesa/main/imports.h b/src/mesa/main/imports.h
index 356f0e1..d886427 100644
Series looks good to me. It's a nice cleanup on its own right.
Reviewed-by: Jose Fonseca jfons...@vmware.com
Jose
On 23/02/15 04:31, Matt Turner wrote:
---
This series is attempting to make some progress towards moving u_math.h
to src/util.
include/c99_compat.h| 143
For series
Reviewed-by: Jose Fonseca jfons...@vmware.com
23/02/15 15:59, Brian Paul wrote:
Also, wrapping the array in #ifdef DEBUG / #endif doesn't seem necessary.
---
src/gallium/auxiliary/util/u_debug.c | 45 +---
1 file changed, 21 insertions(+), 24
Reviewed-by: Jose Fonseca jfons...@vmware.com
On 23/02/15 15:39, Brian Paul wrote:
Bugzilla:
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.freedesktop.org_show-5Fbug.cgi-3Fid-3D89260d=AwIGaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzEm
On 13/02/15 00:49, Eric Anholt wrote:
Jose Fonseca jfons...@vmware.com writes:
Thanks for doing this. I appreciate it.
I have no objection with the series. I'm happy to see more reuse. We
can always move things around later, and it will be much easier when
then are less entangled/duplicated
, BITSET_WORDBITS) / BITSET_WORDBITS)
+#define BITSET_WORDS(bits) ((bits + BITSET_WORDBITS - 1) / BITSET_WORDBITS)
bits - (bits)
just in case...
#define BITSET_DECLARE(name, bits) BITSET_WORD name[BITSET_WORDS(bits)]
/* bitset operations
With it
Reviewed-by: Jose Fonseca jfons...@vmware.com
Add another class of tests.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=89112
I failed to spot this in my previous change, because bool was a typedef
for char on the system I tested.
---
src/util/u_atomic_test.c | 25 +++--
1 file changed, 19 insertions(+), 6
To help identify llvmpipe rasterizer threads -- especially when there
can be so many.
We can eventually generalize this to other OSes, but for that we must
restrict the function to be called from the current thread. See also
http://stackoverflow.com/a/7989973
---
On 13/02/15 15:23, Roland Scheidegger wrote:
Just one trivial issue, otherwise
Reviewed-by: Roland Scheidegger srol...@vmware.com
Am 13.02.2015 um 15:05 schrieb Jose Fonseca:
To help identify llvmpipe rasterizer threads -- especially when there
can be so many.
We can eventually generalize
On 13/02/15 18:52, Ian Romanick wrote:
Starting this morning I'm seeing 'make check' failures in
u_atomic_test. It looks like José was the last person to touch that
area. I haven't investigated any further.
../../bin/test-driver: line 107: 11024 Aborted (core dumped) $@
On 12/02/15 17:03, Brian Paul wrote:
On 02/12/2015 09:27 AM, Jose Fonseca wrote:
We need to build certain parts of Mesa (namely gallium, llvmpipe, and
therefore util) with Windows SDK 7.0.7600, which includes MSVC 2008.
---
src/util/u_atomic.h | 32 ++--
1 file
Thanks for doing this. I appreciate it.
I have no objection with the series. I'm happy to see more reuse. We
can always move things around later, and it will be much easier when
then are less entangled/duplicated.
We'll need to update SCons include paths too. If you have a git repos
with
LGTM.
On 12/02/15 17:31, Tobias Klausmann wrote:
The most common macros are defined there, no use to duplicate these
Clean up the already redefinded macros
Signed-off-by: Tobias Klausmann tobias.johannes.klausm...@mni.thm.de
---
src/gallium/include/pipe/p_compiler.h | 57
We need to build certain parts of Mesa (namely gallium, llvmpipe, and
therefore util) with Windows SDK 7.0.7600, which includes MSVC 2008.
---
src/util/u_atomic.h | 32 ++--
1 file changed, 30 insertions(+), 2 deletions(-)
diff --git a/src/util/u_atomic.h
---
src/util/u_atomic_test.c | 32 +---
1 file changed, 17 insertions(+), 15 deletions(-)
diff --git a/src/util/u_atomic_test.c b/src/util/u_atomic_test.c
index c506275..8bddf8d 100644
--- a/src/util/u_atomic_test.c
+++ b/src/util/u_atomic_test.c
@@ -37,8 +37,9 @@
On 09/02/15 23:25, Sedat Dilek wrote:
On Mon, Feb 9, 2015 at 9:51 PM, Jose Fonseca jfons...@vmware.com wrote:
On 09/02/15 17:44, Emil Velikov wrote:
Hi Sedat,
On 07/02/15 22:42, Sedat Dilek wrote:
[ Please CC me I am not subscribed to mesa-dev and llvmdev MLs ]
Hi,
I already reported
On 06/02/15 22:39, Carl Worth wrote:
On Fri, Feb 06 2015, Aaron Watry wrote:
Ignore me if this is a stupid question, but should those both be
sizeof(short)? I'd expect the first to be sizeof(char).
Not a stupid question. That was a copy-and-paste (kill-and-yank ?) bug
of mine.
Thanks for
On 09/02/15 17:44, Emil Velikov wrote:
Hi Sedat,
On 07/02/15 22:42, Sedat Dilek wrote:
[ Please CC me I am not subscribed to mesa-dev and llvmdev MLs ]
Hi,
I already reported this when playing 1st time with my llvm-toolchain
v3.6.0rc2 and mesa v10.3.7 [1].
The issue still remains in mesa
On 09/02/15 16:59, Jon TURNEY wrote:
On 06/02/2015 19:58, Matt Turner wrote:
On Fri, Feb 6, 2015 at 3:38 AM, Jonathan Gray j...@jsg.id.au wrote:
OpenBSD has ffs in libc but does not have ffsll so use the compiler
builtin. PIPE_OS_BSD isn't suitable here as FreeBSD has ffsll in libc.
incremental solutions. That is, add a
new header to src/util with an unique name, and cherry-pick bits and pieces
from u_math.[ch] as deemed necessary/practical.
Jose
From: Marek Olšák mar...@gmail.com
Sent: 08 February 2015 11:27
To: Jose Fonseca
Cc
On 07/02/15 00:10, Matt Turner wrote:
On Fri, Feb 6, 2015 at 3:58 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
util is meant to be for shared utility across the entire code base -
both Mesa and Gallium. It's been growing slowly as people move things
there. It might make sense to move a
I think we decided not to support unreleased LLVM builds on stable releases.
This is because building without errors is not enough -- there are often
other changes that need to go with this. Furthermore it's often a moving
target.
In short, if you want to use bleeding edge LLVM, you must use
Nothing special needs to be done.
Even though llvmpipe copies constant (ie uniform) buffers internally, the
application is suppose to flush and sync, so all should work.
All bufferstorage piglit tests pass.
---
src/gallium/drivers/llvmpipe/lp_screen.c | 3 ++-
1 file changed, 2 insertions(+), 1
On 05/02/15 15:07, Roland Scheidegger wrote:
Am 05.02.2015 um 15:33 schrieb Jose Fonseca:
Nothing special needs to be done.
Even though llvmpipe copies constant (ie uniform) buffers internally, the
application is suppose to flush and sync, so all should work.
All bufferstorage piglit tests
On 04/02/15 20:18, Kenneth Graunke wrote:
On Wednesday, February 04, 2015 02:04:38 PM Jose Fonseca wrote:
This change broke MinGW/MSVC builds because ffsll is not available there.
There is a ffsll C fallback, but it's in src/mesa/main/imports.[ch]. So
rather than duplicating it in src
This change broke MinGW/MSVC builds because ffsll is not available there.
There is a ffsll C fallback, but it's in src/mesa/main/imports.[ch]. So
rather than duplicating it in src/gallium/auxiliary/util/u_math.h I'd
prefer move it to src/util.
And here lies the problem: what header name
On 16/12/14 20:08, Rob Conde wrote:
I built Mesa 10.4 with LLVM 3.5 today and I had to make a couple of
fixes to get it to work:
1. root\src\mesa\compiler.h
After:
#include c99_compat.h /* inline, __func__, etc. */
Add:
#ifdef _MSC_VER
#define __attribute__(a)
On 29/01/15 21:20, Roland Scheidegger wrote:
Hi,
the address reg in tgsi is quite a nuisance. glsl-to-tgsi code assumes
that indirections can only be done through the address reg and has quite
some extra code to deal with this. Even though hardware and apis which
worked like that are definitely
Looks good to me.
Just one minor suggestion: if we replaced
sizeof(void *) == 8
with
sizeof(void *) sizeof(GLuint)
we would avoid the magic number 8 and make the code correct for any
pointer size.
Jose
On 28/01/15 03:06, Brian Paul wrote:
The _mesa_dlist_alloc() function is only
On 29/01/15 17:14, Kristian Høgsberg wrote:
On Thu, Jan 29, 2015 at 6:36 AM, Emil Velikov emil.l.veli...@gmail.com wrote:
On 28/01/15 05:08, Kristian Høgsberg wrote:
While modern pthread mutexes are very fast, they still incur a call to an
external DSO and overhead of the generality and
On 29/01/15 19:40, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
since the address reg holds integer values, ARL/ARR do an implicit float-to-int
conversion, so clarify that. Thus it is also incorrect to say that FLR really
does the same as ARL.
---
It looks like nobody really cares, so I'll take it as consent.
This only happens if X requires 24bit visuals. Maybe a minority of
drivers do that. At least Intel X driver does.
BTW, this should go to stable branches too.
Jose
On 19/01/15 23:09, Jose Fonseca wrote:
From: José Fonseca jfons
From: José Fonseca jfons...@vmware.com
The dri2_x11_add_configs_for_visuals() function happily matches a 32
bits EGLconfig with a 24 bits X visual. However it was passing 32bits
depth to xcb_put_image(), making X server unhappy:
maybe it would be better to leave the code as it is so that
it's a bit easier to understand.
- Neil
Jose Fonseca jfons...@vmware.com writes:
Yes, the bit shifting can be a crude approximation.
llvmpipe did that everywhere but we had to fix it in a few places, e.g.:
https
On 15/01/15 19:46, Carl Worth wrote:
On Thu, Jan 08 2015, Jose Fonseca wrote:
Note that Windows build is only supported with SCons. Never with
autobuild.
OK. That's good for me to learn. I've requested that the folks doing our
automated build testing here will also start testing scons builds
Yes, the bit shifting can be a crude approximation.
llvmpipe did that everywhere but we had to fix it in a few places, e.g.:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=1569b3e536da9337a28a16d0cc6ed07043bf094b
The multiplication is unavoidable (*), but one can avoid the division of
| 2 +-
src/mesa/state_tracker/st_program.c | 2 +-
src/mesa/vbo/vbo_exec_array.c | 3 ++-
src/util/hash_table.c | 2 +-
30 files changed, 56 insertions(+), 57 deletions(-)
Thanks for this cleanup.
Series looks good AFAICT.
Reviewed-by: Jose Fonseca
On 15/01/15 15:39, Jason Ekstrand wrote:
I just pushed NIR to master. I wanted to write a couple of notes about
the interaction between that code and MSVC and what the current plan
is. Right now, NIR won't build with MSVC; at least not MSVC 2010 (or is
it 11?) as it uses quite a bit of C99.
On 12/01/15 12:32, Iago Toral Quiroga wrote:
Hi Jose,
thanks for reporting this.
On lun, 2015-01-12 at 12:18 +, Jose Fonseca wrote:
Iago, Jason,
There seems to be some bad or missing dependency when building with
automake. I have a build bot that roughly does this every time:
git
Iago, Jason,
There seems to be some bad or missing dependency when building with
automake. I have a build bot that roughly does this every time:
git clean -fdx
mkdir -p build
cd build
../autogen.sh --prefix=/usr --enable-debug --enable-dri3
--enable-gles1 --enable-gles2 --enable-xa
On 07/01/15 19:11, Carl Worth wrote:
On Wed, Jan 07 2015, Jose Fonseca wrote:
I lost bit track of email over the Christmas period. Just noticed I had
flagged this one for replay. Sorry.
No worries. Thanks for following up now. :-)
Do you still need me to test anything on Windows? If so
From: José Fonseca jfons...@vmware.com
We never used ulVersion for proper version checks.
Most 3rd party drivers use version 1, but recently NVIDIA OpenGL driver
started using a version number 1, so the handy trick of renaming Mesa's
ICDs as nvoglv32.dll on Windows machines with NVIDIA hardware
From: José Fonseca jfons...@vmware.com
Trivial.
---
src/mesa/main/imports.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/imports.c b/src/mesa/main/imports.c
index 6945c2f..4f5a2d1 100644
--- a/src/mesa/main/imports.c
+++ b/src/mesa/main/imports.c
@@ -94,7
On 08/01/15 16:57, Brian Paul wrote:
On 01/08/2015 09:41 AM, Jose Fonseca wrote:
From: José Fonseca jfons...@vmware.com
We never used ulVersion for proper version checks.
Most 3rd party drivers use version 1, but recently NVIDIA OpenGL driver
started using a version number 1,
What version
, pixels, true);
- pixels += _mesa_image_image_stride(ctx-Unpack, width, height,
-format, type);
+ pixels = (GLubyte *) pixels + rowStride;
}
}
else {
Looks good to me. Serie is
Reviewed-by: Jose Fonseca jfons
On 08/12/14 19:56, Matt Turner wrote:
See commit 2b7a972e for the Coccinelle script.
[...]
diff --git a/src/mesa/main/imports.c b/src/mesa/main/imports.c
index 4f5a2d1..6945c2f 100644
--- a/src/mesa/main/imports.c
+++ b/src/mesa/main/imports.c
@@ -94,7 +94,7 @@ _mesa_align_malloc(size_t bytes,
, false);
}
}
Looks good to me.
Reviewed-by: Jose Fonseca jfons...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Do we really need a new pipe_context::set_counter_buffer method?
Shouldn't this case be covered by pipe_context::set_shader_resources ?
If we really need new method, I'd like we have better names for them, so
we can clearly distinguish them.
IIUC GL_ARB_shader_atomic_counters correctly, this
/ first_layer/last_layer as structure pointer
parameter, instead of requiring actual views. Which can be done later,
so I suppose this is fine like this.
Reviewed-by: Jose Fonseca jfons...@vmware.com
Jose
---
src/gallium/include/pipe/p_context.h | 11 +++
src/gallium
IIUC, ancillary here means depth/stencil buffer associated with the
framebuffer.
So basically PIPE_FLUSH_INVALIDATE_ANCILLARY you're proposing will
invalidate the currently bound pipe_framebuffer_state::zsbuf.
I think we eventually will want a more general invalidate pipe_context
method,
lp_build_context *bld,
LLVMBuilderRef builder = bld-gallivm-builder;
LLVMValueRef res = bld-undef;
unsigned i;
- LLVMValueRef temp_ptr;
+ LLVMValueRef temp_ptr = NULL;
if (overflow_mask) {
temp_ptr = lp_build_alloca(
Reviewed-by: Jose Fonseca jfons...@vmware.com
+
+
/**
* \name Internal functions
*/
@@ -212,4 +217,9 @@ _mesa_InvalidateTexImage(GLuint texture, GLint level);
/*@}*/
+#ifdef __cplusplus
+}
+#endif
+
+
#endif
Thanks for doing this, Brian. I was about to do it myself.
Series is Reviewed-by: Jose Fonseca jfons...@vmware.com
Is it now
On 11/12/14 22:02, Brian Paul wrote:
On 12/11/2014 02:51 PM, Carl Worth wrote:
From: Kristian Høgsberg k...@bitplanet.net
The upcoming shader cache uses the SHA-1 algorithm for cryptographic
naming. These new mesa_sha1 functions are implemented with the nettle
library.
---
This patch is
From: José Fonseca jfons...@vmware.com
f0ba7d897d1c22202531acb70f134f2edc30557d made debug_assert()/assert()
unsafe for expressions, but only now with u_atomic.h started to rely on
them for Windows this became an issue.
This fixes non-debug builds with MSVC.
---
Series looks nice cleanup.
I don't know of any need to keep support for older GCC neither.
But I don't think it makes sense to mess with gtest -- it's better to
keep this in sync with upstream, and clobber with new upstream versions
when appropriate.
All other changes are
Reviewed-By: Jose
(struct ra_graph *g, unsigned int n)
{
- int j;
+ unsigned int j;
float benefit = 0;
int n_class = g-nodes[n].class;
Reviewed-by: Jose Fonseca jfons...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http
On 12/12/14 20:38, Matt Turner wrote:
José,
As it is now, since we're not building the gbm or egl state trackers
via autotools, they're not included in the tarball created by make
dist. That is, the files in
src/gallium/state_trackers/egl
src/gallium/state_trackers/gbm
wouldn't be
On 12/12/14 20:59, Matt Turner wrote:
On Fri, Dec 12, 2014 at 12:54 PM, Jose Fonseca jfons...@vmware.com wrote:
On 12/12/14 20:38, Matt Turner wrote:
José,
As it is now, since we're not building the gbm or egl state trackers
via autotools, they're not included in the tarball created by make
On 11/12/14 08:40, Emil Velikov wrote:
Hi Jose,
On 10/12/14 14:18, Jose Fonseca wrote:
I never tried, but it doesn't surprise that ?USE_MGL_NAMESPACE doesn't work
properly on Windows.
At very least the src/mesa/drivers/windows/gdi and
src/gallium/targets/libgl-gdi targets will fail because
Overall I think this is a great cleanup.
Just a remark about the chosen names.
On 10/12/14 21:22, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
Plus a new PIPE_CAP_VERTEXID_NOOFFSET query.
Vertex offset and base vertex are difference concepts, so I'd rather
not
Including system's headers inside extern C { ... } is not safe, as system
headers may have C++ code in them, and C++ code inside extern C { .. }
doesn't work.
This is because putting code inside extern C won't make __plusplus define go
away, that is, the headers being included thinks is free
From: José Fonseca jfons...@vmware.com
This is just to help repro and fixing these issues with any C++ compiler --
commiting this will of course wait until all issues are addressed.
$ scons src/glsl/
scons: Reading SConscript files ...
Checking for GCC ... yes
Checking for Clang ... no
OK. I found a way to make it easier to trap this sort of issues going forward,
regardless of compiler. See patch I just posted.
Jose
From: Brian Paul bri...@vmware.com
Sent: 11 December 2014 22:05
To: mesa-dev@lists.freedesktop.org
Cc: Jose Fonseca
I never tried, but it doesn't surprise that ?USE_MGL_NAMESPACE doesn't work
properly on Windows.
At very least the src/mesa/drivers/windows/gdi and
src/gallium/targets/libgl-gdi targets will fail because the .DEF files there
explicitly request the non-mangled symbols.
Not sure if
On 09/12/14 11:28, Marek Olšák wrote:
From: Marek Olšák marek.ol...@amd.com
It's exposed, because I plan to use it elsewhere later.
I hesitate in repeating myself, but I can't close my eyes. This is such
a bad idea, at so many levels.
How will this cope when the application is running on
I'm not particularly knowledgeable about autoconf/make, but it looks
correct AFAICT. Thanks for doing this.
I think it would be useful to also add a comment somewhere on why
-mstackrealign is necessary for 32-bits, for future reference.
Reviewed-by: Jose Fonseca jfons...@vmware.com
Jose
Looks good AFAICT.
But I think we should probably swap the operands only once, in one
place, instead of having two branches for switch_order.
Jose
On 04/12/14 23:25, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
The original idea was to optimize away the condition
On 05/12/14 00:01, Ilia Mirkin wrote:
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
Cc: 10.4 10.3 mesa-sta...@lists.freedesktop.org
---
src/gallium/auxiliary/indices/u_primconvert.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: José Fonseca jfons...@vmware.com
Matches what u_vbuf_get_minmax_index() does.
---
src/gallium/auxiliary/indices/u_primconvert.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/indices/u_primconvert.c
901 - 1000 of 2262 matches
Mail list logo
