[Mesa-dev] Mesa 10.4 has been branched

Hello list, As you'll notice shortly I have just branched the next release branch 10.4 of the master branch. Additionally I've created and pushed a 10.4-branchpoint tag that should ease people searching through mesa's history. The first release candidate tag be that 10.4.0-rc1 or 10.3.99.901 will

[Mesa-dev] [PATCH] mesa: Bump version to 10.5.0-devel.

Signed-off-by: Vinson Lee --- VERSION | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/VERSION b/VERSION index d43f97a..093d8ba 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -10.4.0-devel +10.5.0-devel -- 1.9.2 ___ mesa-dev mailing

Re: [Mesa-dev] [PATCH] mesa: Fix _mesa_uint_array_min_max linker error.

On 11/15/2014 01:20 AM, Timothy Arceri wrote: On Fri, 2014-11-14 at 22:14 +0330, Siavash Eliasi wrote: You are right. Any suggestions on how to fix this build failure? Using this would fix it but the optimisation would be disabled on clang. Not sure how many people are concerned about this, I

Re: [Mesa-dev] [PATCH] mesa: Bump version to 10.5.0-devel.

Hi Vinson, I've deliberately omitted the version update, pending the conclusion of the "Move mesa version scheme to a more common style ?" thread -Emil On 15/11/14 08:50, Vinson Lee wrote: > Signed-off-by: Vinson Lee > --- > VERSION | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >

Re: [Mesa-dev] Move mesa version scheme to a more common style ?

On 14 November 2014 16:48, Ilia Mirkin wrote: > On Fri, Nov 14, 2014 at 11:17 AM, Emil Velikov > wrote: >> On 14/11/14 15:24, Ilia Mirkin wrote: >>> On Fri, Nov 14, 2014 at 9:39 AM, Emil Velikov >>> wrote: Hello all, This is an old question that I had laying around - why doesn't

Re: [Mesa-dev] Move mesa version scheme to a more common style ?

On 14 November 2014 19:50, Ilia Mirkin wrote: > On Fri, Nov 14, 2014 at 9:39 AM, Emil Velikov > wrote: >> Hello all, >> >> This is an old question that I had laying around - why doesn't mesa use >> a more conventional numbering for the development/rc releases ? >> >> Eg. >> mesa 10.4.0-rc1 -> 10

[Mesa-dev] [PATCH 2/2] Revert "mesa: Wrap SSE4.1 code in #ifdef __SSE4_1__."

This reverts commit 8d3f739383fbdf671752fdec707f1c2b9b2aa6a3. In the last commit we've updated our check to determine if the actual code is buildable, rather than if the compiler acknowledges the option. I.e. did anyone provide -mno-sse4.1 vs is my compiler too old. Now this code will never be at

[Mesa-dev] [PATCH 1/2] configure.ac: roll up a program for the sse4.1 check

So when checking/building sse code we have three possibilities: 1 Old compiler, throws an error when using -msse* 2 New compiler, user disables sse* (-mno-sse*) 3 New compiler, user doesn't disable sse The original code, added code for #1 but not #2. Later on we patched around the lack of hand

Re: [Mesa-dev] Move mesa version scheme to a more common style ?

If it helps explain things, X.Org's versioning scheme is documented in: http://www.x.org/releases/X11R7.7/doc/xorg-docs/Versions.html -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc

Re: [Mesa-dev] Move mesa version scheme to a more common style ?

On Sat, Nov 15, 2014 at 6:52 AM, Emil Velikov wrote: > On 14 November 2014 19:50, Ilia Mirkin wrote: >> On Fri, Nov 14, 2014 at 9:39 AM, Emil Velikov >> wrote: >>> Hello all, >>> >>> This is an old question that I had laying around - why doesn't mesa use >>> a more conventional numbering for th

Re: [Mesa-dev] Move mesa version scheme to a more common style ?

I've always found the X.Org versioning scheme unintuitive. This is actually for the first time after ~5 years of contributing to open source graphics that I finally understand how the X versioning works. Granted, I had never been interested in it anyway. If you need to have a web page on x.org tha

Re: [Mesa-dev] [PATCH 2/2] Revert "mesa: Wrap SSE4.1 code in #ifdef __SSE4_1__."

Apply for both patch 1/2 and 2/2. Host: chroot on AMD A3870K Target: AMD TK-55 (compiled with -mno-sse41) I tested chroot cross-compilation and it passed correctly. Tested-by: David Heidelberg On 11/15/2014 06:04 PM, Emil Velikov wrote: This reverts commit 8d3f739383fbdf671752fdec707f1c2b9b2a

Re: [Mesa-dev] [PATCH 1/2] configure.ac: roll up a program for the sse4.1 check

On Sat, Nov 15, 2014 at 12:04 PM, Emil Velikov wrote: > So when checking/building sse code we have three possibilities: > 1 Old compiler, throws an error when using -msse* > 2 New compiler, user disables sse* (-mno-sse*) > 3 New compiler, user doesn't disable sse > > The original code, added co

Re: [Mesa-dev] [PATCH 1/2] configure.ac: roll up a program for the sse4.1 check

On Sat, Nov 15, 2014 at 1:13 PM, Ilia Mirkin wrote: > On Sat, Nov 15, 2014 at 12:04 PM, Emil Velikov > wrote: >> So when checking/building sse code we have three possibilities: >> 1 Old compiler, throws an error when using -msse* >> 2 New compiler, user disables sse* (-mno-sse*) >> 3 New comp

Re: [Mesa-dev] [PATCH 1/2] configure.ac: roll up a program for the sse4.1 check

On Sat, Nov 15, 2014 at 10:13 AM, Ilia Mirkin wrote: > On Sat, Nov 15, 2014 at 12:04 PM, Emil Velikov > wrote: >> So when checking/building sse code we have three possibilities: >> 1 Old compiler, throws an error when using -msse* >> 2 New compiler, user disables sse* (-mno-sse*) >> 3 New com

Re: [Mesa-dev] [PATCH 1/2] configure.ac: roll up a program for the sse4.1 check

On Sat, Nov 15, 2014 at 9:04 AM, Emil Velikov wrote: > So when checking/building sse code we have three possibilities: > 1 Old compiler, throws an error when using -msse* > 2 New compiler, user disables sse* (-mno-sse*) > 3 New compiler, user doesn't disable sse > > The original code, added cod

Re: [Mesa-dev] [PATCH 2/2] Revert "mesa: Wrap SSE4.1 code in #ifdef __SSE4_1__."

On Sat, Nov 15, 2014 at 9:04 AM, Emil Velikov wrote: > This reverts commit 8d3f739383fbdf671752fdec707f1c2b9b2aa6a3. > > In the last commit we've updated our check to determine if the actual > code is buildable, rather than if the compiler acknowledges the option. > I.e. did anyone provide -mno-ss

Re: [Mesa-dev] [PATCH 1/2] configure.ac: roll up a program for the sse4.1 check

On 15/11/14 18:18, Matt Turner wrote: > On Sat, Nov 15, 2014 at 10:13 AM, Ilia Mirkin wrote: >> On Sat, Nov 15, 2014 at 12:04 PM, Emil Velikov >> wrote: >>> So when checking/building sse code we have three possibilities: >>> 1 Old compiler, throws an error when using -msse* >>> 2 New compiler,

Re: [Mesa-dev] [PATCH 1/2] configure.ac: roll up a program for the sse4.1 check

Tested on Core2 Q9550, using -march=native with and without -mno-sse4.1flag. It works perfect :) Also David Heidelberg kindly tested the patch which permanently enables optimized code paths if supported by target machine and it was okay. http://patchwork.freedesktop.org/patch/36488/ And a sma

Re: [Mesa-dev] [PATCH] mesa: Bump version to 10.5.0-devel.

On Sat, Nov 15, 2014 at 3:20 AM, Emil Velikov wrote: > Hi Vinson, > > I've deliberately omitted the version update, pending the conclusion of > the "Move mesa version scheme to a more common style ?" thread Wouldn't the master branch be 10.5.0-devel regardless? ___

Re: [Mesa-dev] [PATCH 1/2] configure.ac: roll up a program for the sse4.1 check

On 15/11/14 18:21, Matt Turner wrote: > On Sat, Nov 15, 2014 at 9:04 AM, Emil Velikov > wrote: >> So when checking/building sse code we have three possibilities: >> 1 Old compiler, throws an error when using -msse* >> 2 New compiler, user disables sse* (-mno-sse*) >> 3 New compiler, user doesn

[Mesa-dev] [PATCH] st/mesa: add a fallback for clear_with_quad when no vs_layer

Not all drivers can set gl_Layer from VS. Add a fallback that passes the instance id from VS to GS, and then uses the GS to set the layer. Tested by adding quad_buffers |= clear_buffers; clear_buffers = 0; to the st_Clear logic, and forcing set_vertex_shader_layered in all cases. No piglit r

[Mesa-dev] [PATCHv2] configure.ac: roll up a program for the sse4.1 check

So when checking/building sse code we have three possibilities: 1 Old compiler, throws an error when using -msse* 2 New compiler, user disables sse* (-mno-sse*) 3 New compiler, user doesn't disable sse The original code, added code for #1 but not #2. Later on we patched around the lack of handl

Re: [Mesa-dev] [PATCH 1/2] configure.ac: roll up a program for the sse4.1 check

On Sat, Nov 15, 2014 at 10:30 AM, Emil Velikov wrote: > On 15/11/14 18:21, Matt Turner wrote: >> On Sat, Nov 15, 2014 at 9:04 AM, Emil Velikov >> wrote: >>> Man this thing is _very_ messy. >>> Matt from the last hunk it seems that pixman might need fixing. Should >>> be bother with that, or let

Re: [Mesa-dev] [PATCHv2] configure.ac: roll up a program for the sse4.1 check

On Sat, Nov 15, 2014 at 10:37 AM, Emil Velikov wrote: > So when checking/building sse code we have three possibilities: > 1 Old compiler, throws an error when using -msse* > 2 New compiler, user disables sse* (-mno-sse*) > 3 New compiler, user doesn't disable sse > > The original code, added co

Re: [Mesa-dev] [PATCH 1/2] configure.ac: roll up a program for the sse4.1 check

On Sat, Nov 15, 2014 at 1:25 PM, Emil Velikov wrote: > On 15/11/14 18:18, Matt Turner wrote: >> On Sat, Nov 15, 2014 at 10:13 AM, Ilia Mirkin wrote: >>> On Sat, Nov 15, 2014 at 12:04 PM, Emil Velikov >>> wrote: So when checking/building sse code we have three possibilities: 1 Old com

Re: [Mesa-dev] [PATCH 1/2] configure.ac: roll up a program for the sse4.1 check

On 15/11/14 18:38, Matt Turner wrote: > On Sat, Nov 15, 2014 at 10:30 AM, Emil Velikov > wrote: >> On 15/11/14 18:21, Matt Turner wrote: >>> On Sat, Nov 15, 2014 at 9:04 AM, Emil Velikov >>> wrote: Man this thing is _very_ messy. Matt from the last hunk it seems that pixman might need

Re: [Mesa-dev] [PATCH] mesa: Bump version to 10.5.0-devel.

On 15/11/14 18:28, Matt Turner wrote: > On Sat, Nov 15, 2014 at 3:20 AM, Emil Velikov > wrote: >> Hi Vinson, >> >> I've deliberately omitted the version update, pending the conclusion of >> the "Move mesa version scheme to a more common style ?" thread > > Wouldn't the master branch be 10.5.0-de

[Mesa-dev] [PATCH] mesa/main: Fix tmp_row memory leak in texstore_rgba_integer.

--- src/mesa/main/texstore.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c index f913e42..f858cef 100644 --- a/src/mesa/main/texstore.c +++ b/src/mesa/main/texstore.c @@ -1667,8 +1667,10 @@ texstore_rgba_integer(TEXSTORE_

Re: [Mesa-dev] [PATCH] mesa/main: Fix tmp_row memory leak in texstore_rgba_integer.

Good catch! Reviewed-by: Jason Ekstrand Can you push or do you need me to? On Sat, Nov 15, 2014 at 11:02 AM, Siavash Eliasi wrote: > --- > src/mesa/main/texstore.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c

Re: [Mesa-dev] [PATCH] st/mesa: add a fallback for clear_with_quad when no vs_layer

On Sat, Nov 15, 2014 at 1:38 PM, Ilia Mirkin wrote: > Not all drivers can set gl_Layer from VS. Add a fallback that passes the > instance id from VS to GS, and then uses the GS to set the layer. > > Tested by adding > > quad_buffers |= clear_buffers; > clear_buffers = 0; > > to the st_Clear lo

Re: [Mesa-dev] [PATCH] st/mesa: add a fallback for clear_with_quad when no vs_layer

Reviewed-by: Marek Olšák Marek On Sat, Nov 15, 2014 at 7:38 PM, Ilia Mirkin wrote: > Not all drivers can set gl_Layer from VS. Add a fallback that passes the > instance id from VS to GS, and then uses the GS to set the layer. > > Tested by adding > > quad_buffers |= clear_buffers; > clear_b

[Mesa-dev] EXT/ARB direct state access extensions

Hello all, I would like to ask what is the status of DSA (direct state access) extensions in mesa. If I understand correctly, there was a GSoC project by Dylan Noblesmith and there currently is a dsa branch in mesa repo, but it's not actively worked on at the moment. Is there any particular reason

[Mesa-dev] [PATCH] scons: Require glproto >= 1.4.13 for X11.

GLXBadProfileARB and X_GLXCreateContextAtrribsARB require glproto >= 1.4.13. These symbols were added in commit d5d41112cbccd9301500e8e023be77eb9cb622cd "st/xlib: Generate errors as specified." Signed-off-by: Vinson Lee Cc: "10.4" --- scons/gallium.py | 2 +- 1 file changed, 1 insertion(+), 1 d

Re: [Mesa-dev] [PATCH] scons: Require glproto >= 1.4.13 for X11.

On Sat, Nov 15, 2014 at 2:16 PM, Vinson Lee wrote: > GLXBadProfileARB and X_GLXCreateContextAtrribsARB require glproto >= > 1.4.13. These symbols were added in commit > d5d41112cbccd9301500e8e023be77eb9cb622cd "st/xlib: Generate errors as > specified." > > Signed-off-by: Vinson Lee > Cc: "10.4"

[Mesa-dev] [Bug 84124] Please revert 8449121971ce1db03fea19665d314e523fdc10dd

https://bugs.freedesktop.org/show_bug.cgi?id=84124 --- Comment #6 from almos --- I noticed that 10.4 has recently been branched, but the release notes doesn't mention this change yet. -- You are receiving this mail because: You are the QA Contact for the bug. ___

[Mesa-dev] [Bug 86326] clEnqueueNDRangeKernel global_work_offset ignored

https://bugs.freedesktop.org/show_bug.cgi?id=86326 Bug ID: 86326 Summary: clEnqueueNDRangeKernel global_work_offset ignored Product: Mesa Version: 10.3 Hardware: x86 (IA32) OS: Linux (All) Status: NEW Seve

[Mesa-dev] [PATCH 1/2] nv50, nvc0: actually check constbufs for invalidation

The number of vertex buffers has nothing to do with the number of bound constbufs. Signed-off-by: Ilia Mirkin Cc: "10.4 10.3" --- src/gallium/drivers/nouveau/nv50/nv50_context.c | 5 +++-- src/gallium/drivers/nouveau/nvc0/nvc0_context.c | 4 +++- 2 files changed, 6 insertions(+), 3 deletions(-)

[Mesa-dev] [PATCH 2/2] nv50, nvc0: buffer resources can be bound as other things down the line

res->bind is not an indicator of how the resource is currently bound. buffers can be rebound across different binding points without changing underlying storage. Signed-off-by: Ilia Mirkin Cc: "10.4 10.3" --- src/gallium/drivers/nouveau/nv50/nv50_context.c | 14 +++--- src/gallium/drive

Re: [Mesa-dev] [PATCH] dri/kms: Always zero out struct drm_mode_create_dumb

On 13/11/14 18:05, Thierry Reding wrote: > From: Thierry Reding > > The DRM_IOCTL_MODE_CREATE_DUMB (and others) IOCTL isn't very rigorously > specified, which has the effect that some kernel drivers do not consider > the .pitch and .size fields of struct drm_mode_create_dumb outputs only. > Inste

Re: [Mesa-dev] [PATCH] mesa/main: Fix tmp_row memory leak in texstore_rgba_integer.

Please push it, I don't have write access. Best regards, Siavash Eliasi. On 11/15/2014 11:06 PM, Jason Ekstrand wrote: Good catch! Reviewed-by: Jason Ekstrand > Can you push or do you need me to? On Sat, Nov 15, 2014 at 11:02 AM, Siavash Eliasi mailto:siava

[Mesa-dev] [Bug 86330] lp_bld_debug.cpp:112: multiple definition of `raw_debug_ostream::write_impl(char const*, unsigned long)'

https://bugs.freedesktop.org/show_bug.cgi?id=86330 Bug ID: 86330 Summary: lp_bld_debug.cpp:112: multiple definition of `raw_debug_ostream::write_impl(char const*, unsigned long)' Product: Mesa Version: git

[Mesa-dev] [PATCH] gallium/include/pipe: Added interface for atomic counter buffers in pipe

--- src/gallium/include/pipe/p_context.h | 5 + src/gallium/include/pipe/p_defines.h | 7 ++- src/gallium/include/pipe/p_state.h | 10 ++ 3 files changed, 21 insertions(+), 1 deletion(-) diff --git a/src/gallium/include/pipe/p_context.h b/src/gallium/include/pipe/p_context.h

[Mesa-dev] [Bug 86330] lp_bld_debug.cpp:112: multiple definition of `raw_debug_ostream::write_impl(char const*, unsigned long)'

https://bugs.freedesktop.org/show_bug.cgi?id=86330 Vinson Lee changed: What|Removed |Added Keywords||bisected --- Comment #1 from Vinson Lee --

[Mesa-dev] tinderbox build regression

no idea but I'm picking Emil as the culprit! Dave. From: http://tinderbox.x.org/builds/2014-11-16-/logs/mesa-mesa/#build make[3]: Entering directory `/home/tinderbox/mesa/mesa/src/gallium/targets/xa' CC libxatracker_la-target.lo CXXLDlibxatracker.la ../../../../src/gallium/auxi

Re: [Mesa-dev] feature request for mesamatrix.net

> I appreciate the work you've done to make the GL3.txt file much more > readable. > To improve it even more I would like to be able to click on the > extensions names and see the whole text of the extension from the > registry on opengl.org. I think it would help to understand why > something isn'