Re: [Mesa3d-dev] Current tinderbox regression (swrastg_dri, sparc64)
On Sun, Mar 28, 2010 at 3:07 PM, Luca Barbieri wrote: > On Sun, Mar 28, 2010 at 7:36 PM, Chris Ball wrote: >> Hi, >> >> > http://tinderbox.x.org/builds/2010-03-25-0018/logs/libGL/#build >> > >> > swrastg_dri.so.tmp: undefined reference to `__sync_sub_and_fetch_4' >> > swrastg_dri.so.tmp: undefined reference to `__sync_add_and_fetch_4' >> >> This regression is still present -- could we get a fix or a revert? > > I believe the problem is that sparc does not support atomic operations > in the basic architecture: I think someone who knows about sparc and > has such a machine should look into it. > > If you don't know anything about sparc, try rebuilding with the > highest possible sparc -march= level and if that fixes the problem, > perform a binary search to find the minimum one, and then report the > results. > > If it does not solve the problem, see if anything in /lib or /usr/lib > exports those symbols. > > Also maybe check whether the built swrastg_dri or xlib softpipe > actually works there. I think we need to be specifying something like -mcpu=v9 or something to be able to use the __sync_* primitives. I highly doubt anyone wants to run any of this code on something older. I've CC'd Dave Miller--he'll know what to do. Thanks, Matt -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Move lists to freedesktop.org?
On Thu, Mar 4, 2010 at 3:37 PM, Jesse Barnes wrote: > Would anyone have objections if these lists moved to freedesktop.org? > The recent thread with Linus about the drm pull request highlights the > post lag and non-subscriber aspect of the current lists, and that > leaves aside sf.net's horrible mail archive interface and poor > performance. > > If spam is an issue, another option would be vger.kernel.org. That > team runs lkml and several other very high traffic, high profile lists > and manages quite well; performance is always high and spam is nearly > non-existent given the amount of traffic. > > -- > Jesse Barnes, Intel Open Source Technology Center As a user and occasional poster to these lists, that sounds very good to me. > -- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev It'd be nice to get rid of these silly advertisements too. Matt -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa removals
On Mon, Feb 22, 2010 at 2:46 PM, Ian Romanick wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Brian Paul wrote: >> Starting a new thread on this... >> >> Here's a proposal of things to remove from the Mesa tree. >> >> GLU: >> glu/mini >> glu/mesa >> >> GLUT: >> glut/fbdev >> glut/ggi >> glut/directfb >> glut/dos >> glut/mini >> glut/os2 >> >> non-DRI drivers: >> drivers/allegro >> drivers/directfb >> drivers/d3d >> drivers/dos >> drivers/ggi >> drivers/glide >> drivers/svga >> >> DRI drivers: >> drivers/dri/fb >> drivers/dri/ffb >> drivers/dri/gamma >> >> progs/directfb >> progs/ggi >> progs/windml >> progs/miniglx >> >> Comments? > > That list looks good to me. I'm a little sad to see gamma go, but > that's mostly sadness that it was never revived after the DRI / DRM > architecture started going a different direction. > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkuC3xkACgkQX1gOwKyEAw/Z6wCeNvkBnT3OuCpeoHwHyILe9/TE > 7jAAn3cNRz7pVgz16/xGOBJPd+J3DwsA > =m62D > -END PGP SIGNATURE- > > -- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > ___ > Mesa3d-dev mailing list > Mesa3d-dev@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev I'm actually in the process of gathering hardware to revive gamma (or rewrite its stack all together). So I don't know whether it should be removed or not. Certainly the mesa component of the stack won't be touched until I get a memory manager working. Matt -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] swrast/sse: Fix _mesa_sse_transform_pointsX_3d_no_rot
On Tue, Feb 2, 2010 at 2:04 PM, Ian Romanick wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Pauli Nieminen wrote: >> PXOR user in code were causing the lowest SP float register to have NaN >> values which made all math operations in that slot fail. Correct istruction >> to clear float registers is XORPS which handles single precission floats >> correctly. >> >> Fixes progs/tests/fog in swrast SSE mode. >> >> Signed-off-by: Pauli Nieminen >> --- >> src/mesa/x86/sse_xform2.S | 2 +- >> src/mesa/x86/sse_xform3.S | 2 +- >> 2 files changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/src/mesa/x86/sse_xform2.S b/src/mesa/x86/sse_xform2.S >> index b490d4c..a443dad 100644 >> --- a/src/mesa/x86/sse_xform2.S >> +++ b/src/mesa/x86/sse_xform2.S >> @@ -186,7 +186,7 @@ GLNAME(_mesa_sse_transform_points2_3d_no_rot): >> MOV_L( REGOFF(V4F_START, EDI), EDI ) /* ptr to first dest vertex */ >> ADD_L( EDI, ECX ) /* count += dest ptr */ >> >> - PXOR( XMM0, XMM0 ) >> + XORPS( XMM0, XMM0 ) /* clean the working >> register */ > > (Showing ignorance here...) Is XORPS available in all of the flavors of > SSE that this code is supposed to support? I assume that it is... Yes, it's been there since SSE1. (PXOR is the MMX mnemonic that was extended to support SSE registers.) >> ALIGNTEXT32 >> MOVSS ( M(0), XMM1 ) /* - | - | - | m0 */ >> diff --git a/src/mesa/x86/sse_xform3.S b/src/mesa/x86/sse_xform3.S >> index 8a79eed..4bc22d8 100644 >> --- a/src/mesa/x86/sse_xform3.S >> +++ b/src/mesa/x86/sse_xform3.S >> @@ -198,7 +198,7 @@ GLNAME(_mesa_sse_transform_points3_3d_no_rot): >> MOV_L( REGOFF(V4F_START, EDI), EDI ) /* ptr to first dest vertex */ >> ADD_L( EDI, ECX ) /* count += dest ptr */ >> >> - PXOR( XMM0, XMM0 ) >> + XORPS( XMM0, XMM0 ) /* clean the working >> register */ >> >> ALIGNTEXT32 >> MOVSS ( M(0), XMM1 ) /* - | - | - | m0 */ > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAktodyYACgkQX1gOwKyEAw+UqACeIPZw1dkHgf/UBvcym9dgOSxw > h88AnjCdZSex5HHC9gUK/GKjcEgMNVwS > =6KIc > -END PGP SIGNATURE- > > -- > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://p.sf.net/sfu/theplanet-com > ___ > Mesa3d-dev mailing list > Mesa3d-dev@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev > -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [RFC] Move _mesa_memcpy to imports.h and inline it
Most of the functions in imports.c are very small, to the function
call overhead is large relative to their size. Can't we do something
like in the attached patch and move them to imports.h and mark them
static inline? Things like memcpy and memset are often optimized out
by the compiler, and by hiding them in these wrapper functions, we're
probably losing any benefits we'd otherwise see. Similarly, if we're
going to use a magic sqrtf algorithm (apparently for speed) then
shouldn't we also let the compiler properly inline the function?
I also don't quite understand wrapper functions like
double
_mesa_pow(double x, double y)
{
return pow(x, y);
}
Maybe at one time these had #ifdefs in them like _mesa_memcpy, but I
can't see any reason not to remove it now.
Someone enlighten me.
Thanks,
Matt Turner
move-mesa-memcpy-to-imports.h.patch
Description: Binary data
--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] minor u_math.h speedup fun
On Sat, Nov 28, 2009 at 2:13 PM, Yang Zhao wrote: > The speed-up is definitely there, but __builtin_popcount() will still > be drastically faster when architecture-specific optimizations are > enabled: I don't think this is the case (except for with SSE4's popcnt instruction, which your CFLAGS seem to be enabling.) Even when compiling with the Intel CC, which can undoubtedly can optimize code for Core 2 better than gcc, fast_bitcount is significantly faster. $ icc -O3 -ipo -march=core2 bc.c -o bc ipo: remark #11001: performing single-file optimizations ipo: remark #11005: generating object file /tmp/ipo_icce1aegt.o bc.c(61): (col. 5) remark: LOOP WAS VECTORIZED. $ ./bc 1 billion of __builtin_popcount(), fast_bitcount(), and naive() (in that order) __builtin_popcount(): 5.361 seconds fast_bitcount(): 1.274 seconds kr_bitcount(): 20.302 seconds naive(): 34.547 seconds Matt -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] minor u_math.h speedup fun
Results from my 2 GHz Core 2. __builtin_popcount(): 11.709 seconds fast_bitcount(): 3.956 seconds kr_bitcount(): 24.276 seconds naive(): 38.493 seconds Nothing even compares to fast_bitcount. Matt -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Fwd: RFC: libdrm repo
On Sun, Nov 22, 2009 at 8:30 PM, wrote: [snip] I wasn't going to say anything, but I feel that I have to. Please don't top quote. Also, don't send awful HTML email. Matt -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [r300-gallium] compiling against recent libdrm
Hi,
Looks to me like a lot of whitespace changes were included in the
patch. Is this intended?
Matt
On Mon, Jul 13, 2009 at 3:48 PM, Nicolai Hähnle wrote:
> Hey there,
>
> I hacked together the following patch to make Gallium compile against recent
> libdrm. Does it seem right to you?
>
> ---
> src/gallium/drivers/r300/r300_context.h | 4 +-
> src/gallium/drivers/r300/r300_query.h | 2 +
> src/gallium/drivers/r300/r300_screen.h | 2 +-
> src/gallium/drivers/softpipe/sp_winsys.h | 12 ++--
> src/gallium/winsys/drm/radeon/core/radeon_buffer.c | 10 ++-
> src/gallium/winsys/drm/radeon/core/radeon_buffer.h | 13 +---
> src/gallium/winsys/drm/radeon/core/radeon_drm.c | 16 +++--
> src/gallium/winsys/drm/radeon/core/radeon_r300.c | 74
> +---
> src/gallium/winsys/drm/radeon/core/radeon_r300.h | 7 ++
> 9 files changed, 57 insertions(+), 83 deletions(-)
>
> diff --git a/src/gallium/drivers/r300/r300_context.h
> b/src/gallium/drivers/r300/r300_context.h
> index ae78574..e56cfcc 100644
> --- a/src/gallium/drivers/r300/r300_context.h
> +++ b/src/gallium/drivers/r300/r300_context.h
> @@ -217,7 +217,7 @@ struct r300_texture {
>
> /* Stride (pitch?) of this texture in bytes */
> unsigned stride;
> -
> +
> /* Total size of this texture, in bytes. */
> unsigned size;
>
> @@ -331,7 +331,7 @@ struct r300_context {
> };
>
> /* Convenience cast wrapper. */
> -static struct r300_context* r300_context(struct pipe_context* context) {
> +static INLINE struct r300_context* r300_context(struct pipe_context* context)
> {
> return (struct r300_context*)context;
> }
>
> diff --git a/src/gallium/drivers/r300/r300_query.h
> b/src/gallium/drivers/r300/r300_query.h
> index 4f447ea..6a76460 100644
> --- a/src/gallium/drivers/r300/r300_query.h
> +++ b/src/gallium/drivers/r300/r300_query.h
> @@ -27,6 +27,8 @@
> #include "r300_cs.h"
> #include "r300_reg.h"
>
> +struct r300_context;
> +
> struct r300_query {
> /* The kind of query. Currently only OQ is supported. */
> unsigned type;
> diff --git a/src/gallium/drivers/r300/r300_screen.h
> b/src/gallium/drivers/r300/r300_screen.h
> index 3f52dbc..2a0e41f 100644
> --- a/src/gallium/drivers/r300/r300_screen.h
> +++ b/src/gallium/drivers/r300/r300_screen.h
> @@ -49,7 +49,7 @@ struct r300_transfer {
> };
>
> /* Convenience cast wrapper. */
> -static struct r300_screen* r300_screen(struct pipe_screen* screen) {
> +static INLINE struct r300_screen* r300_screen(struct pipe_screen* screen) {
> return (struct r300_screen*)screen;
> }
>
> diff --git a/src/gallium/drivers/softpipe/sp_winsys.h
> b/src/gallium/drivers/softpipe/sp_winsys.h
> index 9e57186..6eeb3f3 100644
> --- a/src/gallium/drivers/softpipe/sp_winsys.h
> +++ b/src/gallium/drivers/softpipe/sp_winsys.h
> @@ -1,8 +1,8 @@
> /**
> - *
> + *
> * Copyright 2007 Tungsten Graphics, Inc., Cedar Park, Texas.
> * All Rights Reserved.
> - *
> + *
> * Permission is hereby granted, free of charge, to any person obtaining a
> * copy of this software and associated documentation files (the
> * "Software"), to deal in the Software without restriction, including
> @@ -10,11 +10,11 @@
> * distribute, sub license, and/or sell copies of the Software, and to
> * permit persons to whom the Software is furnished to do so, subject to
> * the following conditions:
> - *
> + *
> * The above copyright notice and this permission notice (including the
> * next paragraph) shall be included in all copies or substantial portions
> * of the Software.
> - *
> + *
> * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
> * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
> @@ -22,7 +22,7 @@
> * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
> * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
> * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
> - *
> + *
> **/
>
> /* This is the interface that softpipe requires any window system
> @@ -40,7 +40,9 @@ extern "C" {
> #endif
>
>
> +struct pipe_buffer;
> struct pipe_screen;
> +struct pipe_texture;
> struct pipe_winsys;
> struct pipe_context;
>
> diff --git a/src/gallium/winsys/drm/radeon/core/radeon_buffer.c
> b/src/gallium/winsys/drm/radeon/core/radeon_buffer.c
> index 263f684..275ab99 100644
> --- a/src/gallium/winsys/drm/radeon/core/radeon_buffer.c
> +++ b/src/gallium/winsys/drm/radeon/core/radeon_buffer.c
> @@ -1,8 +1,8 @@
> -/*
> +/*
> * Copyright © 2008 Jérôme Glisse
> * 2009 Corbin Simpson
> * All Rights Reserved.
> - *
> + *
> * Permission is hereby granted, free of charge, to any person obtaining
> * a copy of this software and associated documentation file
Re: [Mesa3d-dev] More radeon-rewrite patches
> 2) handle big endian machines correctly > Is this really an issue? I think this is important -- PowerPC, for instance. Thanks for your excellent work. Matt Turner -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
