On 23/07/15 01:08, Jose Fonseca wrote:
On 23/07/15 01:00, Brian Paul wrote:
On 07/22/2015 05:31 PM, Jose Fonseca wrote:
On 22/07/15 23:32, Brian Paul wrote:
Hi Marek,
This is regarding your commit st/mesa: use pipe_sampler_view_release
for releasing sampler views from last October
Use MSVCRT functions instead. Their semantics are slightly
different but they can be made to work as expected.
Also, use the same code paths for both MSVCRT and MinGW.
No testing yet. Just built.
https://bugs.freedesktop.org/show_bug.cgi?id=91418
---
src/gallium/auxiliary/Makefile.sources |
On 22/07/15 16:04, Emil Velikov wrote:
Otherwise the final dri module will have (additional) unresolved
symbols.
Cc: Brian Paul bri...@vmware.com
Cc: Jose Fonseca jfons...@vmware.com
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
We can only fix the remaining unresolved symbols
On 21/07/15 15:57, Emil Velikov wrote:
On 18 July 2015 at 08:13, Jose Fonseca jfons...@vmware.com wrote:
On 18/07/15 01:38, Eric Anholt wrote:
Emil Velikov emil.l.veli...@gmail.com writes:
On 14/07/15 19:45, Eric Anholt wrote:
These are really useful hints to the compiler in the absence
On 22/07/15 17:13, Jose Fonseca wrote:
On 21/07/15 15:57, Emil Velikov wrote:
On 18 July 2015 at 08:13, Jose Fonseca jfons...@vmware.com wrote:
On 18/07/15 01:38, Eric Anholt wrote:
Emil Velikov emil.l.veli...@gmail.com writes:
On 14/07/15 19:45, Eric Anholt wrote:
These are really
On 22/07/15 21:01, Jose Fonseca wrote:
On 22/07/15 17:13, Jose Fonseca wrote:
On 21/07/15 15:57, Emil Velikov wrote:
On 18 July 2015 at 08:13, Jose Fonseca jfons...@vmware.com wrote:
On 18/07/15 01:38, Eric Anholt wrote:
Emil Velikov emil.l.veli...@gmail.com writes:
On 14/07/15 19:45
On 22/07/15 23:32, Brian Paul wrote:
Hi Marek,
This is regarding your commit st/mesa: use pipe_sampler_view_release
for releasing sampler views from last October.
Basically, we have:
void
st_texture_release_all_sampler_views(struct st_context *st,
struct
On 23/07/15 01:00, Brian Paul wrote:
On 07/22/2015 05:31 PM, Jose Fonseca wrote:
On 22/07/15 23:32, Brian Paul wrote:
Hi Marek,
This is regarding your commit st/mesa: use pipe_sampler_view_release
for releasing sampler views from last October.
Basically, we have:
void
) {
- raw_debug_ostream Out;
- Out LLVMGetValueName(func) :\n;
- disassemble(code, Out);
+ _debug_printf(%s:\n, LLVMGetValueName(func));
+ disassemble(code);
}
Series looks good AFAICT.
Reviewed-by: Jose Fonseca jfons...@vmware.com
___
mesa-dev mailing
On 18/07/15 01:38, Eric Anholt wrote:
Emil Velikov emil.l.veli...@gmail.com writes:
On 14/07/15 19:45, Eric Anholt wrote:
These are really useful hints to the compiler in the absence of link-time
optimization, and I'm going to use them in VC4.
I've made the const attribute be ATTRIBUTE_CONST
/include/c99_math.h
@@ -140,6 +140,12 @@ llrintf(float f)
return rounded;
}
+static inline float
+exp2f(float f)
+{
+ return powf(2.0f, f);
+}
+
#endif /* C99 */
Looks good. Thanks.
Reviewed-by: Jose Fonseca jfons...@vmware.com
___
mesa-dev
From: Tom Hughes t...@compton.nu
https://bugs.freedesktop.org/show_bug.cgi?id=90817
Signed-off-by: Jose Fonseca jfons...@vmware.com
---
src/glx/dri_common.c | 59 +++-
1 file changed, 58 insertions(+), 1 deletion(-)
diff --git a/src/glx
Reviewed-by: Jose Fonseca jfons...@vmware.com
On 14/07/15 16:02, Emil Velikov wrote:
It has been broken since 2011 with commit c98ea26e16b(egl: Make
egl_dri2 and egl_glx built-in drivers.). When the backends got merged
into the main library each entry point was guarded
On 12/07/15 01:49, Ilia Mirkin wrote:
On Thu, Jul 2, 2015 at 4:54 PM, Jose Fonseca jfons...@vmware.com wrote:
On 02/07/15 19:45, Ilia Mirkin wrote:
On Thu, Jul 2, 2015 at 2:31 PM, Jose Fonseca jfons...@vmware.com wrote:
On 02/07/15 17:49, Ilia Mirkin wrote:
On Thu, Jul 2, 2015 at 12:40
On 09/07/15 22:05, Marek Olšák wrote:
I'd like to discuss one more thing that will affect whether image
slots will be global (shared by all shaders) or not.
Which image unit an image uniform uses is not a compile-time thing,
but it's specified later using glUniform1i. That means we need a
I'm not experienced with the semantics around resources that can be
read/written by shaders, so I can't really make educated comments.
But overall this looks good to me FWIW.
On 05/07/15 14:25, Marek Olšák wrote:
From: Marek Olšák marek.ol...@amd.com
Other approaches are being considered:
On 07/07/15 21:28, Ilia Mirkin wrote:
On Tue, Jul 7, 2015 at 4:24 PM, Jose Fonseca jfons...@vmware.com wrote:
I'm not experienced with the semantics around resources that can be
read/written by shaders, so I can't really make educated comments.
But overall this looks good to me FWIW.
On 05/07
mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Reviewed-by: Jose Fonseca jfons...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 02/07/15 06:55, Matt Turner wrote:
On Wed, Jul 1, 2015 at 3:22 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
The optimization logic relies on being able to read out constbuf values
from program parameters. However that only works if there's no relative
addressing involved.
Bugzilla:
On 01/07/15 00:33, Julien Isorce wrote:
darwin: silence GLhandleARB convertions from and to GLuint
This patch and its description are inspired from Jose Fonseca
explanations and suggestions.
With this patch the following logic applies and only if __APPLE__:
When building mesa, GLhandleARB
On 02/07/15 13:16, Emil Velikov wrote:
On 1 July 2015 at 00:33, Julien Isorce julien.iso...@gmail.com wrote:
darwin: silence GLhandleARB convertions from and to GLuint
This patch and its description are inspired from Jose Fonseca
explanations and suggestions.
With this patch the following
On 02/07/15 19:45, Ilia Mirkin wrote:
On Thu, Jul 2, 2015 at 2:31 PM, Jose Fonseca jfons...@vmware.com wrote:
On 02/07/15 17:49, Ilia Mirkin wrote:
On Thu, Jul 2, 2015 at 12:40 PM, Jose Fonseca jfons...@vmware.com wrote:
On 02/07/15 17:24, Ilia Mirkin wrote:
On Thu, Jul 2, 2015 at 12:17
On 02/07/15 16:34, Ilia Mirkin wrote:
On Thu, Jul 2, 2015 at 1:55 AM, Jose Fonseca jfons...@vmware.com wrote:
On 01/07/15 22:30, bugzilla-dae...@freedesktop.org wrote: *Comment # 14
https://bugs.freedesktop.org/show_bug.cgi?id=91173#c14
on bug 91173 https://bugs.freedesktop.org/show_bug.cgi?id
On 02/07/15 17:08, Ilia Mirkin wrote:
On Thu, Jul 2, 2015 at 11:57 AM, Jose Fonseca jfons...@vmware.com wrote:
On 02/07/15 16:34, Ilia Mirkin wrote:
On Thu, Jul 2, 2015 at 1:55 AM, Jose Fonseca jfons...@vmware.com wrote:
On 01/07/15 22:30, bugzilla-dae...@freedesktop.org wrote: *Comment
On 02/07/15 17:39, Ilia Mirkin wrote:
On Thu, Jul 2, 2015 at 12:24 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Thu, Jul 2, 2015 at 12:17 PM, Jose Fonseca jfons...@vmware.com wrote:
On 02/07/15 17:08, Ilia Mirkin wrote:
On Thu, Jul 2, 2015 at 11:57 AM, Jose Fonseca jfons...@vmware.com
On 02/07/15 17:24, Ilia Mirkin wrote:
On Thu, Jul 2, 2015 at 12:17 PM, Jose Fonseca jfons...@vmware.com wrote:
On 02/07/15 17:08, Ilia Mirkin wrote:
On Thu, Jul 2, 2015 at 11:57 AM, Jose Fonseca jfons...@vmware.com wrote:
On 02/07/15 16:34, Ilia Mirkin wrote:
On Thu, Jul 2, 2015 at 1:55
On 02/07/15 17:49, Ilia Mirkin wrote:
On Thu, Jul 2, 2015 at 12:40 PM, Jose Fonseca jfons...@vmware.com wrote:
On 02/07/15 17:24, Ilia Mirkin wrote:
On Thu, Jul 2, 2015 at 12:17 PM, Jose Fonseca jfons...@vmware.com wrote:
Ah OK. So I guess tilers will have to disable their render queues
On 01/07/15 22:30, bugzilla-dae...@freedesktop.org wrote: *Comment # 14
https://bugs.freedesktop.org/show_bug.cgi?id=91173#c14
on bug 91173 https://bugs.freedesktop.org/show_bug.cgi?id=91173 from
Ilia Mirkin mailto:imir...@alum.mit.edu *
Erm... ok...
MOV R0.zw, c[A0.x + 9];
MOV R1.x,
On 26/06/15 12:05, Marek Olšák wrote:
From: Marek Olšák marek.ol...@amd.com
This will be used by radeon and amdgpu winsyses.
Copied from the amdgpu winsys.
---
src/gallium/auxiliary/os/os_time.c | 36 +++-
src/gallium/auxiliary/os/os_time.h | 10 ++
2
As others pointed, volatile and atomic are slightly different things,
but you have point: atomic operations should probably take volatile
pointers as arguments.
This is what C11 did
http://en.cppreference.com/w/c/atomic/atomic_load
so I do believe that it makes sense to update p_atomic
, pt);
- pipe_surface_release(pipe, strb-surface);
-
st_update_renderbuffer_surface(st, strb);
strb-Base.Format = st_pipe_format_to_mesa_format(pt-format);
Reviewed-by: Jose Fonseca jfons...@vmware.com
___
mesa-dev mailing list
mesa-dev
On 22/06/15 17:14, Ian Romanick wrote:
On 06/19/2015 06:08 AM, Jose Fonseca wrote:
When input and output varyings started to be counted separately (commit
42305fb5) the is_varying_var function wasn't updated to return true for
output varyings or input varyings for stages other than the fragment
On 22/06/15 19:51, Emil Velikov wrote:
On 22 June 2015 at 15:01, Jose Fonseca jfons...@vmware.com wrote:
On 19/06/15 23:09, Emil Velikov wrote:
On 19 June 2015 at 21:26, Jose Fonseca jfons...@vmware.com wrote:
On 19/06/15 20:56, Emil Velikov wrote:
Hi all,
A lovely series inspired (more
On 23/06/15 15:36, Jose Fonseca wrote:
On 22/06/15 17:14, Ian Romanick wrote:
On 06/19/2015 06:08 AM, Jose Fonseca wrote:
When input and output varyings started to be counted separately (commit
42305fb5) the is_varying_var function wasn't updated to return true for
output varyings or input
On 22/06/15 19:40, Florian Link wrote:
Hi everyone,
I spent some time building Mesa/llvmpipe on Windows and created a Python
script
that implements all the required steps (downloading/extracting all
prerequisites and sources,
configuring and building LLVM and Mesa).
The script is available at:
On 19/06/15 23:09, Emil Velikov wrote:
On 19 June 2015 at 21:26, Jose Fonseca jfons...@vmware.com wrote:
On 19/06/15 20:56, Emil Velikov wrote:
Hi all,
A lovely series inspired (more like 'was awaken to send these out') by
Pal Rohár, who was having issues when building xlib-libgl (plus
On 19/06/15 20:56, Emil Velikov wrote:
Hi all,
A lovely series inspired (more like 'was awaken to send these out') by
Pal Rohár, who was having issues when building xlib-libgl (plus the now
enabled gles*)
So here, we teach the final two static glapi users about shared-glapi,
plus some related
When input and output varyings started to be counted separately (commit
42305fb5) the is_varying_var function wasn't updated to return true for
output varyings or input varyings for stages other than the fragment
shader), effectively making the varying limit to never be checked.
With this change,
---
src/glsl/link_varyings.cpp | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/src/glsl/link_varyings.cpp b/src/glsl/link_varyings.cpp
index 7b2d4bd..278a778 100644
--- a/src/glsl/link_varyings.cpp
+++ b/src/glsl/link_varyings.cpp
@@ -1540,13 +1540,15 @@
I only did minor tweaks to these files, but the series LGTM.
Reviewed-by: Jose Fonseca jfons...@vmware.com
On 19/06/15 13:21, Emil Velikov wrote:
Identical to the previous commit - unused by neither the Autotools,
Android or SCons build.
XXX: There are no more users
On 19/06/15 04:46, Ian Romanick wrote:
On 06/17/2015 10:53 PM, Julien Isorce wrote:
From: Jon TURNEY jon.tur...@dronecode.org.uk
On darwin, GLhandleARB is defined as a void *, not the unsigned int it is on
linux.
For the moment, apply a cast to supress the warning
Possibly this is safe, as
Tested with Ilia Mirkin's gzdoom.trace and
arb_uniform_buffer_object-maxuniformblocksize fsexceed piglit test
without my earlier fix to fail linkage when UBO exceeds
GL_MAX_UNIFORM_BLOCK_SIZE.
---
src/gallium/auxiliary/gallivm/lp_bld_limits.h | 6 +-
src/gallium/drivers/llvmpipe/lp_setup.c
On 16/06/15 15:29, Ilia Mirkin wrote:
On Tue, Jun 16, 2015 at 10:22 AM, Roland Scheidegger srol...@vmware.com wrote:
This looks like a good idea to me.
That said, llvmpipe would still crash if the declared size in the shader
wouldn't exceed the max uniform block size, but the bound buffer does
It's not totally clear whether other Mesa drivers can safely cope with
over-sized UBOs, but at least for llvmpipe receiving a UBO larger than
its limit causes problems, as it won't fit into its internal display
lists.
This fixes piglit arb_uniform_buffer_object-maxuniformblocksize
fsexceed
Series looks good to me AFAICT. Thanks for doing this.
Reviewed-by: Jose Fonseca jfons...@vmware.com
Jose
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
PIPE_QUIRK_TEXTURE_BORDER_COLOR_SWIZZLE_NV50 (1 0)
Reviewed-by: Jose Fonseca jfons...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 05/05/15 11:50, Juha-Pekka Heikkila wrote:
If _mesa_hash_table_create failed we'd get null pointer. Report
error and go away.
Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com
---
src/mesa/main/formats.c | 10 ++
1 file changed, 10 insertions(+)
diff --git
Indeed I don't see any reason not to use util_resource_copy_region.
In fact, it might actually fix some bugs, as llvmpipe_transfer_map()
which has some extra smarts for tracking diry constant buffers, which
was not being exercised by lp_resource_copy().
Reviewed-by: Jose Fonseca jfons
the
users don't even know about them.
Marek
On Tue, Jun 9, 2015 at 6:01 PM, Rob Clark robdcl...@gmail.com wrote:
On Tue, Jun 9, 2015 at 9:32 AM, Roland Scheidegger srol...@vmware.com wrote:
Am 09.06.2015 um 15:00 schrieb Rob Clark:
On Tue, Jun 9, 2015 at 5:01 AM, Jose Fonseca jfons
I'm not sure what you are trying to accomplish.
if you're doing some sort of serialization of OpenGL calls other than
GLX, then it might be worthwhile to look at
https://github.com/apitrace/apitrace/blob/master/specs/glapi.py
On 09/06/15 04:03, Rob Clark wrote:
On Mon, Jun 8, 2015 at 10:50 PM, Roland Scheidegger srol...@vmware.com wrote:
Am 09.06.2015 um 04:40 schrieb Rob Clark:
On Mon, Jun 8, 2015 at 10:36 PM, Roland Scheidegger srol...@vmware.com wrote:
Am 09.06.2015 um 04:20 schrieb Rob Clark:
On Mon, Jun 8,
We're only using fairly portable standard Unix calls here, so might as
well save ourselves future trouble by enabling on all Unices by default.
https://bugs.freedesktop.org/show_bug.cgi?id=90904
---
src/gallium/auxiliary/rtasm/rtasm_execmem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On 09/06/15 03:00, Roland Scheidegger wrote:
Am 08.06.2015 um 09:33 schrieb Chih-Sheng Lin:
Hi,
I am working on parallelizing softpipe of Mesa-9.1 by using OpenMP.
My idea is trying to do sp_setup_tri in parallel with multiple threads.
So first in the function sp_vbuf_draw_elements, I
leave defined(__linux__) there, as this code
should not be built on run on Windows profile builds.
With that, this is
Reviewed-by: Jose Fonseca jfons...@vmware.com
Jose
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org
Sounds good in principle. I'm actually surprised this was happening
already. I always use llvmpipe the the non-DRI pure XLIB state tracker
which already does this.
Two comments:
- There's src/gallium/winsys/sw/xlib/xlib_sw_winsys.c which implements
this. I wonder if it would be
I think we had a discussion about this on mesa3d-dev a while ago. I
don't recall the conclusions but I wish I did.
We have tgsi_return_type. Why isn't this enough? Or better, why isn't
being used for this?
Jose
On 04/06/15 16:50, Rob Clark wrote:
From: Rob Clark robcl...@freedesktop.org
On 04/06/15 20:36, Rob Clark wrote:
On Thu, Jun 4, 2015 at 3:22 PM, Rob Clark robdcl...@gmail.com wrote:
On Thu, Jun 4, 2015 at 3:11 PM, Jose Fonseca jfons...@vmware.com wrote:
On 04/06/15 19:50, Rob Clark wrote:
On Thu, Jun 4, 2015 at 2:14 PM, Jose Fonseca jfons...@vmware.com wrote:
I
On 31/05/15 08:10, Tapani wrote:
I've read this a couple of times now and cannot spot any users of
storage that would be making a wrong assumption, you've fixed these and
I trust Jenkins was OK for i915?
Everything is ok if you remove 'I think' and 'Hopefully' from commit
message :)
Martin's
On 04/06/15 11:53, Jose Fonseca wrote:
On 04/06/15 11:23, Martin Peres wrote:
On 04/06/15 13:07, Jose Fonseca wrote:
On 04/06/15 10:56, Martin Peres wrote:
On 04/06/15 12:53, Jose Fonseca wrote:
On 31/05/15 08:10, Tapani wrote:
I've read this a couple of times now and cannot spot any users
On 04/06/15 11:23, Martin Peres wrote:
On 04/06/15 13:07, Jose Fonseca wrote:
On 04/06/15 10:56, Martin Peres wrote:
On 04/06/15 12:53, Jose Fonseca wrote:
On 31/05/15 08:10, Tapani wrote:
I've read this a couple of times now and cannot spot any users of
storage that would be making a wrong
On 04/06/15 19:14, Jose Fonseca wrote:
I think we had a discussion about this on mesa3d-dev a while ago. I
don't recall the conclusions but I wish I did.
Found it:
http://lists.freedesktop.org/archives/mesa-dev/2014-November/thread.html#71577
http://lists.freedesktop.org/archives/mesa-dev
On 04/06/15 19:50, Rob Clark wrote:
On Thu, Jun 4, 2015 at 2:14 PM, Jose Fonseca jfons...@vmware.com wrote:
I think we had a discussion about this on mesa3d-dev a while ago. I don't
recall the conclusions but I wish I did.
We have tgsi_return_type. Why isn't this enough? Or better, why
On 04/06/15 10:56, Martin Peres wrote:
On 04/06/15 12:53, Jose Fonseca wrote:
On 31/05/15 08:10, Tapani wrote:
I've read this a couple of times now and cannot spot any users of
storage that would be making a wrong assumption, you've fixed these and
I trust Jenkins was OK for i915?
Everything
any uniform storage to built-in uniforms */
- if (!storage-builtin)
+ if (storage-builtin)
continue;
if (location != last_location) {
Thanks for digging into it so quickly.
Reviewed-by: Jose Fonseca jfons...@vmware.com
Looks perfect. Thanks!
Jose
On 03/06/15 00:35, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
Pretty trivial, fixes the issue that we're expected to be able to blit
stencil surfaces (as the blit just relies on util blitter code which needs
stencil export to do it).
2
*/
LP_CHECK_MEMBER_OFFSET(struct pipe_vertex_buffer, stride,
target, vb_type, 0);
LP_CHECK_MEMBER_OFFSET(struct pipe_vertex_buffer, buffer_offset,
Series LGTM.
Reviewed-by: Jose Fonseca jfons...@vmware.com
The reasons these warnings are popping up is because we're using
system's
On 28/05/15 19:26, Roland Scheidegger wrote:
Looks ok, it's massively simpler and shouldn't break as often.
Reviewed-by: Roland Scheidegger srol...@vmware.com
Am 28.05.2015 um 17:57 schrieb Jose Fonseca:
It doesn't do everything we want. In particular it doesn't allow to
detect jumps
Rendering from multiple processes into the same X window is not
something that works in practice anymore.
Nowadays interprocess rendering is better done with GLX/EGL extensions
for that effect.
https://bugs.freedesktop.org/show_bug.cgi?id=30279
---
src/xdemos/.gitignore | 1 -
It's incompletete -- it wasn't filling ReferenceType so it was causing
garbagge on the disassembly. Furthermore it seems impossible to get the
jump information through this interface.
The solution for function size problem is to effectively book-keep the
machine code start and end address while
Hi Michel,
I'm sorry: I hadn't notice your review-request, and just pushed a
similar fix.
I used push/pop_macro pragma instead. I think it's portable enough (at
least gcc and msvc support it). Your's is probable more portable
though. I'm OK either way.
Like you said, this is a
For the record, we also feel the pain, and I did look into the LLVM C
API for disassembly, but the problem is that we only get the function
start address -- we don't know where it finishes --, and the LLVM C API
doesn't expose enough capabilities to describe jump/return instructions,
which we
---
src/gallium/auxiliary/gallivm/lp_bld_init.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_init.c
b/src/gallium/auxiliary/gallivm/lp_bld_init.c
index 7b906c2..384ea86 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_init.c
+++
On 28/05/15 15:37, Roland Scheidegger wrote:
Am 28.05.2015 um 16:35 schrieb Jose Fonseca:
---
src/gallium/auxiliary/gallivm/lp_bld_init.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_init.c
b/src/gallium/auxiliary/gallivm/lp_bld_init.c
It doesn't do everything we want. In particular it doesn't allow to
detect jumps or return opcodes. Currently we detect the x86's RET
opcode.
Even though it's worse for LLVM 3.3, it's an improvement for LLVM 3.7,
which was totally busted.
---
scons/llvm.py |
On 21/05/15 02:02, Dylan Baker wrote:
From: Dylan Baker dylanx.c.ba...@intel.com
This results in slightly less code, but code that is much more readable.
It has the advantage of putting everything together in one place, all of
the code is self documenting, help messages are auto-generated,
argparse type is a nice type saver for simple data types, but it doesn't
look a good fit for the input XML file:
- Certain implementations of argparse (particularly python 2.7.3's)
invoke the type constructor for the default argument even when an
option is passed in the command line. Causing
On 26/05/15 19:06, Dylan Baker wrote:
On Tue, May 26, 2015 at 11:15:36AM +0100, Jose Fonseca wrote:
argparse type is a nice type saver for simple data types, but it doesn't
look a good fit for the input XML file:
- Certain implementations of argparse (particularly python 2.7.3's)
invoke
On 26/05/15 19:48, Jose Fonseca wrote:
On 26/05/15 19:06, Dylan Baker wrote:
On Tue, May 26, 2015 at 11:15:36AM +0100, Jose Fonseca wrote:
argparse type is a nice type saver for simple data types, but it doesn't
look a good fit for the input XML file:
- Certain implementations of argparse
-by: Jose Fonseca jfons...@vmware.com
Jose
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
ctx;
Looks good. Thanks.
Reviewed-by: Jose Fonseca jfons...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
and don't know beforehand
which attributes should be listed as active or not. But if it fixes
piglit sounds good to me, as I assume piglit tests are correct.
Acked-by: Jose Fonseca jfons...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
I think there are two different things here: one is the driver
internally fakes BGRX with BGRA, and obviously it's the pipe driver that
needs to fix up alpha channel blending to simulate it's one.
The other is the state tracker is faking BGRX with BGRA, and in that
case, it's the state
, /* st */
},
update_blend, /* update */
Series LGTM.
Reviewed-by: Jose Fonseca jfons...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http
On 29/04/15 15:56, Brian Paul wrote:
On 04/29/2015 05:52 AM, Marek Olšák wrote:
On Wed, Apr 29, 2015 at 12:44 PM, Jose Fonseca jfons...@vmware.com
wrote:
I think there are two different things here: one is the driver
internally
fakes BGRX with BGRA, and obviously it's the pipe driver
On 28/04/15 12:22, Emil Velikov wrote:
On 28 April 2015 at 11:16, Jose Fonseca jfons...@vmware.com wrote:
Hi,
I don't know if in the end of this thread there was an agreement that Valve
should only use bundled libstdc++ if it's newer than the system's libstdc++,
or just no agreement at all
It's returning random values, because RESOURCE_VAR() is casting
different objects into ir_variable pointers.
This updates _mesa_count_active_attribs to filters the resources with
the same logic used in _mesa_longest_attribute_name_length.
https://bugs.freedesktop.org/show_bug.cgi?id=90207
P.S.:
Hi,
I don't know if in the end of this thread there was an agreement that
Valve should only use bundled libstdc++ if it's newer than the system's
libstdc++, or just no agreement at all.
But just for future reference (or in case any distro decides to apply
the patches themselves), I'd like
On 27/04/15 11:23, olivier.pena...@gmail.com wrote:
From: Olivier Pena op...@isagri.fr
llvm/Config/llvm-config.h is parsed instead of llvm/Config/config.h for
detecting LLVM version
(http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-June/073707.html)
---
scons/llvm.py | 33
Pushed. Thanks.
Jose
On 22/04/15 16:36, olivier.pena...@gmail.com wrote:
From: Olivier Pena op...@isagri.fr
---
src/gallium/SConscript| 5
src/gallium/state_trackers/osmesa/Makefile.am | 2 ++
src/gallium/state_trackers/osmesa/SConscript | 26
for the summary.
I'll commit your patch shortly.
Jose
-Message d'origine-
De : mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] De la part de
Jose Fonseca
Envoyé : lundi 27 avril 2015 16:28
À : olivier.pena...@gmail.com; mesa-dev@lists.freedesktop.org
Objet : Re: [Mesa-dev] [PATCH] scons
On 23/04/15 18:46, Pali Rohár wrote:
On Monday 13 April 2015 22:35:03 Pali Rohár wrote:
On Monday 13 April 2015 22:32:10 Brian Paul wrote:
On 04/13/2015 01:49 PM, Pali Rohár wrote:
On Monday 13 April 2015 21:26:32 Pali Rohár wrote:
File glapi_entrypoint.c calls memcpy() function, but does
draw_prim_assembler_prepare_outputs(struct draw_assembler *ia);
+void
+draw_prim_assembler_new_instance(struct draw_assembler *ia);
+
#endif
Looks good to me.
Reviewed-by: Jose Fonseca jfons...@vmware.com
___
mesa-dev mailing list
mesa-dev
Olivier PENA
Envoyé : vendredi 10 avril 2015 11:38
À : Jose Fonseca; Emil Velikov; olivier.pena...@gmail.com
Cc : ML mesa-dev
Objet : Re: [Mesa-dev] [PATCH] scons: add target gallium-osmesa
Hi,
I treated your requests and I'm going to send another patch.
Thanks
-Message d'origine-
De : mesa
I took the liberty to push a follow-up change to rename `interface` to
`program `programInterface`.
`interface` caused build failures on Windows, as it is a define -- an
alias for `struct` keyword, used when declaring COM interfaces in C or C++.
I chose `programInterface` to match the the
On 15/04/15 23:25, Rob Clark wrote:
On Wed, Apr 15, 2015 at 6:15 PM, Ian Romanick i...@freedesktop.org wrote:
On 04/15/2015 10:56 AM, Emil Velikov wrote:
On 15 April 2015 at 18:33, Matt Turner matts...@gmail.com wrote:
On Wed, Apr 15, 2015 at 7:08 AM, Emil Velikov emil.l.veli...@gmail.com
On 14/04/15 17:22, Ian Romanick wrote:
On 04/14/2015 08:36 AM, Emil Velikov wrote:
On 14 April 2015 at 13:52, Jose Fonseca jfons...@vmware.com wrote:
On 13/04/15 22:59, Ian Romanick wrote:
On 04/10/2015 03:36 PM, Jose Fonseca wrote:
From: José Fonseca jfons...@vmware.com
The latest
On 15/04/15 20:38, Brian Paul wrote:
On 04/15/2015 11:56 AM, Emil Velikov wrote:
On 15 April 2015 at 18:33, Matt Turner matts...@gmail.com wrote:
On Wed, Apr 15, 2015 at 7:08 AM, Emil Velikov
emil.l.veli...@gmail.com wrote:
Rather than forcing everyone to provide their own definition of the
);
}
Makes sense AFAICT. But I confess I'm not very familiar with these
subtle interactions between GLX and X server.
Acked-by: Jose Fonseca jfons...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org
As pointed out by Shervin Sharifi.
---
src/mesa/main/dlopen.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/dlopen.h b/src/mesa/main/dlopen.h
index 1e77849..4d20ff2 100644
--- a/src/mesa/main/dlopen.h
+++ b/src/mesa/main/dlopen.h
@@ -50,7 +50,7 @@
- Use GetModuleHandle instead of LoadLibrary to avoid incrementing the
opengl32.dll reference count (otherwise the opengl32.dll will linger
in memory forever.)
- Ensure we use our fake wglCreateContext/wglDeleteContext when using
Mesa as a drop-in replacement for opengl32.dll
Untested.
701 - 800 of 2262 matches
Mail list logo
