mesa3d-dev

[Mesa3d-dev] Move lists to freedesktop.org?

[Jesse B. <jb...@vi...>]

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

Re: [Mesa3d-dev] Mesa (master): mesa: Fix unsigned comparison.

[Brian P. <br...@vm...>]

Michel Dänzer wrote:
> On Thu, 2010-03-04 at 02:00 -0800, Vinson Lee wrote: 
>> Michel, thanks for spotting this.
>>
>> I've reverted the bad commit. Please go ahead and submit your correct fix.
> 
> Actually, I wonder if something like the below isn't needed to avoid any
> undesired effects from integer overflows.
> 
> 
> diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c
> index 326ad6f..8460265 100644
> --- a/src/mesa/main/api_validate.c
> +++ b/src/mesa/main/api_validate.c
> @@ -130,6 +130,7 @@ check_index_bounds(GLcontext *ctx, GLsizei count, GLenum type,
>     struct _mesa_prim prim;
>     struct _mesa_index_buffer ib;
>     GLuint min, max;
> +   GLint64 min64, max64;
>  
>     /* Only the X Server needs to do this -- otherwise, accessing outside
>      * array/BO bounds allows application termination.
> @@ -146,9 +147,12 @@ check_index_bounds(GLcontext *ctx, GLsizei count, GLenum type,
>     ib.obj = ctx->Array.ElementArrayBufferObj;
>  
>     vbo_get_minmax_index(ctx, &prim, &ib, &min, &max);
> +   min64 = min;
> +   min64 += basevertex;
> +   max64 = max;
> +   max64 += basevertex;
>  
> -   if (min + basevertex < 0 ||
> -       max + basevertex > ctx->Array.ArrayObj->_MaxElement) {
> +   if (min64 < 0 || max64 > ctx->Array.ArrayObj->_MaxElement) {
>        /* the max element is out of bounds of one or more enabled arrays */
>        _mesa_warning(ctx, "glDrawElements() index=%u is "
>  		    "out of bounds (max=%u)", max, ctx->Array.ArrayObj->_MaxElement);

I'd be happy with a simple cast for now.  One of these days we'll need 
to be concerned with 4GB buffers (or 2GB buffers and signed 
arithmetic) but we're not quite there yet.  There'd probably be other 
issues to fix.  The buffer object code will need to be audited.

Generally, when fixing signed / unsigned comparison warnings I cast 
the unsigned value to signed, Vinson.

-Brian

Re: [Mesa3d-dev] Mesa (master): mesa: Fix unsigned comparison.

[Michel D. <mi...@da...>]

On Thu, 2010-03-04 at 02:00 -0800, Vinson Lee wrote: 
> Michel, thanks for spotting this.
> 
> I've reverted the bad commit. Please go ahead and submit your correct fix.

Actually, I wonder if something like the below isn't needed to avoid any
undesired effects from integer overflows.


diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c
index 326ad6f..8460265 100644
--- a/src/mesa/main/api_validate.c
+++ b/src/mesa/main/api_validate.c
@@ -130,6 +130,7 @@ check_index_bounds(GLcontext *ctx, GLsizei count, GLenum type,
    struct _mesa_prim prim;
    struct _mesa_index_buffer ib;
    GLuint min, max;
+   GLint64 min64, max64;
 
    /* Only the X Server needs to do this -- otherwise, accessing outside
     * array/BO bounds allows application termination.
@@ -146,9 +147,12 @@ check_index_bounds(GLcontext *ctx, GLsizei count, GLenum type,
    ib.obj = ctx->Array.ElementArrayBufferObj;
 
    vbo_get_minmax_index(ctx, &prim, &ib, &min, &max);
+   min64 = min;
+   min64 += basevertex;
+   max64 = max;
+   max64 += basevertex;
 
-   if (min + basevertex < 0 ||
-       max + basevertex > ctx->Array.ArrayObj->_MaxElement) {
+   if (min64 < 0 || max64 > ctx->Array.ArrayObj->_MaxElement) {
       /* the max element is out of bounds of one or more enabled arrays */
       _mesa_warning(ctx, "glDrawElements() index=%u is "
 		    "out of bounds (max=%u)", max, ctx->Array.ArrayObj->_MaxElement);


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer

[Mesa3d-dev] [PATCH][RFC] porting code from old nouveau driver?

[<ran...@gm...>]

Mesa commit 	93115c4b235896df097b91edec7458a8a4488c4e deleted some interesting 
code i want to resurrect.

Mostly code from old src/mesa/drivers/dri/nouveau/nv04_swtcl.c

I tried to include #include "tnl_dd/t_dd_tritmp.h" directly into nv04_render.c 
and after this compilation fail (with gcc 4.4.3). Guess i need to include it 
somewhat differently?

../../../../../src/mesa/tnl_dd/t_dd_tritmp.h:766: error: 'TAG' defined as 
function, returning function

Re: [Mesa3d-dev] Build error messages in building Progs/Tests

[STEVE555 <ste...@ho...>]

Hi George.
               I've pulled that last commit  and did a rebuild with the same
variables,and progs/tests compiles successfully!
Thank you very much.
Regards,
            STEVE555

STEVE555 wrote:
> 
> Here is some additional information when I was trying to build Mesa with
> the latest commits today:
> 
> gcc -c -I. -I../../include -g -O2 -Wall -Wmissing-prototypes -std=c99
> -ffast-math -fvisibility=hidden -fno-strict-aliasing -m32 -g  -fPIC -m32
> -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE
> -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XCB
> -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
> -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XEXTPROTO_71 -D_GNU_SOURCE
> -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XCB
> -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
> -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XEXTPROTO_71 arraytexture.c
> -o arraytexture.o
> gcc -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math
> -fvisibility=hidden -fno-strict-aliasing -m32 -g  -fPIC -m32 -DUSE_X86_ASM
> -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS
> -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1
> -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING
> -DHAVE_ALIAS -DHAVE_XEXTPROTO_71 arraytexture.o readtex.o -L../../lib
> -lglut -lGLEW -lGLU -lGL  -lm -o arraytexture
> gcc -I. -I../../include -g -O2 -Wall -Wmissing-prototypes -std=c99
> -ffast-math -fvisibility=hidden -fno-strict-aliasing -m32 -g  -fPIC -m32
> -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE
> -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XCB
> -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
> -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XEXTPROTO_71  auxbuffer.c
> -L../../lib -lglut -lGLEW -lGLU -lGL  -lm -o auxbuffer
> auxbuffer.c: In function ‘event_loop’:
> auxbuffer.c:422: warning: implicit declaration of function
> ‘glWindowPos2iARB’
> /usr/bin/ld: /tmp/cchlqm9X.o: undefined reference to symbol
> 'XLookupKeysym'
> /usr/bin/ld: note: 'XLookupKeysym' is defined in DSO /usr/lib/libX11.so.6
> so try adding it to the linker command line
> /usr/lib/libX11.so.6: could not read symbols: Invalid operation
> collect2: ld returned 1 exit status
> gmake[2]: *** [auxbuffer] Error 1
> gmake[2]: Leaving directory `/opt/mesa/progs/tests'
> gmake[1]: *** [subdirs] Error 1
> gmake[1]: Leaving directory `/opt/mesa/progs'
> gmake: *** [default] Error 1
> 
> I hope this can be of more help in solving the problem.
> Regards,
>             STEVE555
> 

-- 
View this message in context: http://old.nabble.com/Build-error-messages-in-building-Progs-Tests-tp27575588p27782008.html
Sent from the mesa3d-dev mailing list archive at Nabble.com.

[Mesa3d-dev] gallium-winsys-handle-rebased branch

[Keith W. <ke...@vm...>]

This branch is hopefully ready for broader testing ahead of a merge.

Can people, especially nv people, pull this down and try it out.  Jakob
has made a best effort to get this right, but neither of us have
hardware.

The branch itself is the start of a significant cleanup of some of the
uglier bits of gallium, particularly the integration with cross-process
shared surfaces, swapbuffers, etc.

Keith

Re: [Mesa3d-dev] Build error messages in building Progs/Tests

[George S. <gsa...@gm...>]

should be fixed now in master

On Thu, Mar 4, 2010 at 4:21 PM, STEVE555 <ste...@ho...> wrote:
>
> I've got closer in solving my problem to get progs/tests to build.Here's what
> I did:
> I edited  my ld.so.conf and and put just one space under the code in there
> /usr and /usr/lib directly underneath.
> I then ran ldconfig.Then I opened up Konsole as root on the Mesa folder and
> I ran these commands:
> export LD__LIBRARY_PATH=/usr
> export PKG_CONFIG_PATH=/usr
> I pressed return on both of those commands,did a gmake -B realclean..I also
> did a git pull origin to get the latest commits.
> I then issued my new ./confiigure options:
> ./configure --prefix=/usr --enable-32-bit --enable-xcb
> --enable-gallium-nouveau --with-state-trackers=dri,egl,xorg,glx,vega,es
> --enable-motif --enable-gl-osmesa --disable-gallium-intel
> --disable-gallium-radeon --with-expat=/usr/lib
> --with-demos=xdemos,demos,trivial,tests --with-dri-drivers=swrast
> --enable-gallium-swrast --enable-gallium-svga --with-max-width=4096
> --with-max-height=4096
>
> Then I ran gmake.The build got past the error  I posted earlier,,but it
> stops at this new error:
>
> gcc -I. -I../../include -g -O2 -Wall -Wmissing-prototypes -std=c99
> -ffast-math -fvisibility=hidden -fno-strict-aliasing -m32 -g  -fPIC -m32
> -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE
> -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1
> -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS
> -DHAVE_XEXTPROTO_71 -DMAX_WIDTH=4096 -DMAX_HEIGHT=4096  fptest1.c
> -L../../lib -lglut -lGLEW -lGLU -lGL  -lm -o fptest1
> gcc -I. -I../../include -g -O2 -Wall -Wmissing-prototypes -std=c99
> -ffast-math -fvisibility=hidden -fno-strict-aliasing -m32 -g  -fPIC -m32
> -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE
> -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1
> -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS
> -DHAVE_XEXTPROTO_71 -DMAX_WIDTH=4096 -DMAX_HEIGHT=4096  fptexture.c
> -L../../lib -lglut -lGLEW -lGLU -lGL  -lm -o fptexture
> python getprocaddress.py > getproclist.h
> Traceback (most recent call last):
>  File "getprocaddress.py", line 8, in <module>
>    import gl_XML
> ImportError: No module named gl_XML
> gmake[2]: *** [getproclist.h] Error 1
> gmake[2]: Leaving directory `/opt/mesa/progs/tests'
> gmake[1]: *** [subdirs] Error 1
> gmake[1]: Leaving directory `/opt/mesa/progs'
> gmake: *** [default] Error 1
>
> I''ve noticed thhat there is a patch named  " Fix syntax screw ups
> introduced in 016fc30, 6e8e4b9 and f7dde2c" both on Nabble and in my Hotmail
> account,I''m thinking  about applying that patch and see if it fixes the
> problem.
>
> Regards,
>            STEVE555
>
>
> STEVE555 wrote:
>>
>> Here is some additional information when I was trying to build Mesa with
>> the latest commits today:
>>
>> gcc -c -I. -I../../include -g -O2 -Wall -Wmissing-prototypes -std=c99
>> -ffast-math -fvisibility=hidden -fno-strict-aliasing -m32 -g  -fPIC -m32
>> -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE
>> -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XCB
>> -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
>> -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XEXTPROTO_71 -D_GNU_SOURCE
>> -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XCB
>> -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
>> -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XEXTPROTO_71 arraytexture.c
>> -o arraytexture.o
>> gcc -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math
>> -fvisibility=hidden -fno-strict-aliasing -m32 -g  -fPIC -m32 -DUSE_X86_ASM
>> -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS
>> -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1
>> -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING
>> -DHAVE_ALIAS -DHAVE_XEXTPROTO_71 arraytexture.o readtex.o -L../../lib
>> -lglut -lGLEW -lGLU -lGL  -lm -o arraytexture
>> gcc -I. -I../../include -g -O2 -Wall -Wmissing-prototypes -std=c99
>> -ffast-math -fvisibility=hidden -fno-strict-aliasing -m32 -g  -fPIC -m32
>> -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE
>> -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XCB
>> -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
>> -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XEXTPROTO_71  auxbuffer.c
>> -L../../lib -lglut -lGLEW -lGLU -lGL  -lm -o auxbuffer
>> auxbuffer.c: In function ‘event_loop’:
>> auxbuffer.c:422: warning: implicit declaration of function
>> ‘glWindowPos2iARB’
>> /usr/bin/ld: /tmp/cchlqm9X.o: undefined reference to symbol
>> 'XLookupKeysym'
>> /usr/bin/ld: note: 'XLookupKeysym' is defined in DSO /usr/lib/libX11.so.6
>> so try adding it to the linker command line
>> /usr/lib/libX11.so.6: could not read symbols: Invalid operation
>> collect2: ld returned 1 exit status
>> gmake[2]: *** [auxbuffer] Error 1
>> gmake[2]: Leaving directory `/opt/mesa/progs/tests'
>> gmake[1]: *** [subdirs] Error 1
>> gmake[1]: Leaving directory `/opt/mesa/progs'
>> gmake: *** [default] Error 1
>>
>> I hope this can be of more help in solving the problem.
>> Regards,
>>             STEVE555
>>
>
> --
> View this message in context: http://old.nabble.com/Build-error-messages-in-building-Progs-Tests-tp27575588p27781381.html
> Sent from the mesa3d-dev mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> 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
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>

Re: [Mesa3d-dev] Build error messages in building Progs/Tests

[STEVE555 <ste...@ho...>]

I've got closer in solving my problem to get progs/tests to build.Here's what
I did:
I edited  my ld.so.conf and and put just one space under the code in there
/usr and /usr/lib directly underneath.
I then ran ldconfig.Then I opened up Konsole as root on the Mesa folder and
I ran these commands:
export LD__LIBRARY_PATH=/usr
export PKG_CONFIG_PATH=/usr
I pressed return on both of those commands,did a gmake -B realclean..I also
did a git pull origin to get the latest commits.
I then issued my new ./confiigure options:
./configure --prefix=/usr --enable-32-bit --enable-xcb
--enable-gallium-nouveau --with-state-trackers=dri,egl,xorg,glx,vega,es
--enable-motif --enable-gl-osmesa --disable-gallium-intel
--disable-gallium-radeon --with-expat=/usr/lib
--with-demos=xdemos,demos,trivial,tests --with-dri-drivers=swrast
--enable-gallium-swrast --enable-gallium-svga --with-max-width=4096
--with-max-height=4096 

Then I ran gmake.The build got past the error  I posted earlier,,but it
stops at this new error:

gcc -I. -I../../include -g -O2 -Wall -Wmissing-prototypes -std=c99
-ffast-math -fvisibility=hidden -fno-strict-aliasing -m32 -g  -fPIC -m32
-DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE
-DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1
-DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS
-DHAVE_XEXTPROTO_71 -DMAX_WIDTH=4096 -DMAX_HEIGHT=4096  fptest1.c
-L../../lib -lglut -lGLEW -lGLU -lGL  -lm -o fptest1
gcc -I. -I../../include -g -O2 -Wall -Wmissing-prototypes -std=c99
-ffast-math -fvisibility=hidden -fno-strict-aliasing -m32 -g  -fPIC -m32
-DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE
-DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1
-DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS
-DHAVE_XEXTPROTO_71 -DMAX_WIDTH=4096 -DMAX_HEIGHT=4096  fptexture.c
-L../../lib -lglut -lGLEW -lGLU -lGL  -lm -o fptexture
python getprocaddress.py > getproclist.h
Traceback (most recent call last):
  File "getprocaddress.py", line 8, in <module>
    import gl_XML
ImportError: No module named gl_XML
gmake[2]: *** [getproclist.h] Error 1
gmake[2]: Leaving directory `/opt/mesa/progs/tests'
gmake[1]: *** [subdirs] Error 1
gmake[1]: Leaving directory `/opt/mesa/progs'
gmake: *** [default] Error 1

I''ve noticed thhat there is a patch named  " Fix syntax screw ups
introduced in 016fc30, 6e8e4b9 and f7dde2c" both on Nabble and in my Hotmail
account,I''m thinking  about applying that patch and see if it fixes the
problem.

Regards,
            STEVE555 


STEVE555 wrote:
> 
> Here is some additional information when I was trying to build Mesa with
> the latest commits today:
> 
> gcc -c -I. -I../../include -g -O2 -Wall -Wmissing-prototypes -std=c99
> -ffast-math -fvisibility=hidden -fno-strict-aliasing -m32 -g  -fPIC -m32
> -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE
> -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XCB
> -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
> -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XEXTPROTO_71 -D_GNU_SOURCE
> -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XCB
> -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
> -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XEXTPROTO_71 arraytexture.c
> -o arraytexture.o
> gcc -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math
> -fvisibility=hidden -fno-strict-aliasing -m32 -g  -fPIC -m32 -DUSE_X86_ASM
> -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS
> -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1
> -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING
> -DHAVE_ALIAS -DHAVE_XEXTPROTO_71 arraytexture.o readtex.o -L../../lib
> -lglut -lGLEW -lGLU -lGL  -lm -o arraytexture
> gcc -I. -I../../include -g -O2 -Wall -Wmissing-prototypes -std=c99
> -ffast-math -fvisibility=hidden -fno-strict-aliasing -m32 -g  -fPIC -m32
> -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE
> -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XCB
> -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
> -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XEXTPROTO_71  auxbuffer.c
> -L../../lib -lglut -lGLEW -lGLU -lGL  -lm -o auxbuffer
> auxbuffer.c: In function ‘event_loop’:
> auxbuffer.c:422: warning: implicit declaration of function
> ‘glWindowPos2iARB’
> /usr/bin/ld: /tmp/cchlqm9X.o: undefined reference to symbol
> 'XLookupKeysym'
> /usr/bin/ld: note: 'XLookupKeysym' is defined in DSO /usr/lib/libX11.so.6
> so try adding it to the linker command line
> /usr/lib/libX11.so.6: could not read symbols: Invalid operation
> collect2: ld returned 1 exit status
> gmake[2]: *** [auxbuffer] Error 1
> gmake[2]: Leaving directory `/opt/mesa/progs/tests'
> gmake[1]: *** [subdirs] Error 1
> gmake[1]: Leaving directory `/opt/mesa/progs'
> gmake: *** [default] Error 1
> 
> I hope this can be of more help in solving the problem.
> Regards,
>             STEVE555
> 

-- 
View this message in context: http://old.nabble.com/Build-error-messages-in-building-Progs-Tests-tp27575588p27781381.html
Sent from the mesa3d-dev mailing list archive at Nabble.com.

Re: [Mesa3d-dev] Mesa (master): mesa: Fix unsigned comparison.

[Vinson L. <vl...@vm...>]

Michel, thanks for spotting this.

I've reverted the bad commit. Please go ahead and submit your correct fix.

________________________________________
From: Michel Dänzer [mi...@da...]
Sent: Thursday, March 04, 2010 1:41 AM
To: Vinson Lee
Cc: mes...@li...
Subject: Re: Mesa (master): mesa: Fix unsigned comparison.

On Thu, 2010-03-04 at 01:27 -0800, Vinson Lee wrote:
> Module: Mesa
> Branch: master
> Commit: f9504e75f02586a8561733e0e2711c65efa2979d
> URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=f9504e75f02586a8561733e0e2711c65efa2979d
>
> Author: Vinson Lee <vl...@vm...>
> Date:   Thu Mar  4 01:24:44 2010 -0800
>
> mesa: Fix unsigned comparison.
>
> ---
>
>  src/mesa/main/api_validate.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c
> index 326ad6f..80bc826 100644
> --- a/src/mesa/main/api_validate.c
> +++ b/src/mesa/main/api_validate.c
> @@ -147,7 +147,7 @@ check_index_bounds(GLcontext *ctx, GLsizei count, GLenum type,
>
>     vbo_get_minmax_index(ctx, &prim, &ib, &min, &max);
>
> -   if (min + basevertex < 0 ||
> +   if (min < basevertex ||

That's not equivalent, is it? Something like

   if ((basevertex < 0 && min < -basevertex) ||

should be.


--
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer

Re: [Mesa3d-dev] Mesa (master): mesa: Fix unsigned comparison.

[Michel D. <mi...@da...>]

On Thu, 2010-03-04 at 01:27 -0800, Vinson Lee wrote: 
> Module: Mesa
> Branch: master
> Commit: f9504e75f02586a8561733e0e2711c65efa2979d
> URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=f9504e75f02586a8561733e0e2711c65efa2979d
> 
> Author: Vinson Lee <vl...@vm...>
> Date:   Thu Mar  4 01:24:44 2010 -0800
> 
> mesa: Fix unsigned comparison.
> 
> ---
> 
>  src/mesa/main/api_validate.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c
> index 326ad6f..80bc826 100644
> --- a/src/mesa/main/api_validate.c
> +++ b/src/mesa/main/api_validate.c
> @@ -147,7 +147,7 @@ check_index_bounds(GLcontext *ctx, GLsizei count, GLenum type,
>  
>     vbo_get_minmax_index(ctx, &prim, &ib, &min, &max);
>  
> -   if (min + basevertex < 0 ||
> +   if (min < basevertex ||

That's not equivalent, is it? Something like

   if ((basevertex < 0 && min < -basevertex) ||

should be.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer

Re: [Mesa3d-dev] [PATCH] Fix syntax screw ups introduced in 016fc30, 6e8e4b9 and f7dde2c.

[Ian R. <id...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This should already be fixed.  Sorry for the noise.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuPG/AACgkQX1gOwKyEAw/bqgCffi8cMZUH0+nePKUphtUInOMz
QgAAn1wmaT3jZzTGzngfDXIfAaKu4bmW
=SlKd
-----END PGP SIGNATURE-----

[Mesa3d-dev] [PATCH] Fix syntax screw ups introduced in 016fc30, 6e8e4b9 and f7dde2c.

[Ingmar V. <in...@ex...>]

From: Bo Ørsted Andresen <zl...@ex...>

---
 src/glx/indirect.h           |    2 +-
 src/glx/indirect_size.c      |    2 +-
 src/glx/indirect_size.h      |    2 +-
 src/mesa/glapi/gen/gl_XML.py |    2 +-
 src/mesa/glapi/glapitemp.h   |    2 +-
 src/mesa/main/compiler.h     |    2 +-
 6 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/glx/indirect.h b/src/glx/indirect.h
index 7064bfe..5c56f4f 100644
--- a/src/glx/indirect.h
+++ b/src/glx/indirect.h
@@ -37,7 +37,7 @@
  * \author Ian Romanick <id...@us...>
  */
 
-#  if defined(__GNUC__) || (defined(__SUNPRO_C) && (__SUNPRO_C >= 0x590))) && defined(__ELF__)
+#  if (defined(__GNUC__) || (defined(__SUNPRO_C) && (__SUNPRO_C >= 0x590))) && defined(__ELF__)
 #    define HIDDEN  __attribute__((visibility("hidden")))
 #  else
 #    define HIDDEN
diff --git a/src/glx/indirect_size.c b/src/glx/indirect_size.c
index 5a8f27b..af15a2e 100644
--- a/src/glx/indirect_size.c
+++ b/src/glx/indirect_size.c
@@ -41,7 +41,7 @@
 #    define FASTCALL
 #  endif
 
-#  if defined(__GNUC__) || (defined(__SUNPRO_C) && (__SUNPRO_C >= 0x590))) && defined(__ELF__)
+#  if (defined(__GNUC__) || (defined(__SUNPRO_C) && (__SUNPRO_C >= 0x590))) && defined(__ELF__)
 #    define INTERNAL  __attribute__((visibility("internal")))
 #  else
 #    define INTERNAL
diff --git a/src/glx/indirect_size.h b/src/glx/indirect_size.h
index 43f504a..a6445af 100644
--- a/src/glx/indirect_size.h
+++ b/src/glx/indirect_size.h
@@ -48,7 +48,7 @@
 #    define FASTCALL
 #  endif
 
-#  if defined(__GNUC__) || (defined(__SUNPRO_C) && (__SUNPRO_C >= 0x590))) && defined(__ELF__)
+#  if (defined(__GNUC__) || (defined(__SUNPRO_C) && (__SUNPRO_C >= 0x590))) && defined(__ELF__)
 #    define INTERNAL  __attribute__((visibility("internal")))
 #  else
 #    define INTERNAL
diff --git a/src/mesa/glapi/gen/gl_XML.py b/src/mesa/glapi/gen/gl_XML.py
index b769ee2..15db87b 100644
--- a/src/mesa/glapi/gen/gl_XML.py
+++ b/src/mesa/glapi/gen/gl_XML.py
@@ -224,7 +224,7 @@ class gl_print_base:
 		"""
 
 		self.undef_list.append(S)
-		print """#  if defined(__GNUC__) || (defined(__SUNPRO_C) && (__SUNPRO_C >= 0x590))) && defined(__ELF__)
+		print """#  if (defined(__GNUC__) || (defined(__SUNPRO_C) && (__SUNPRO_C >= 0x590))) && defined(__ELF__)
 #    define %s  __attribute__((visibility("%s")))
 #  else
 #    define %s
diff --git a/src/mesa/glapi/glapitemp.h b/src/mesa/glapi/glapitemp.h
index f9b803e..92023c3 100644
--- a/src/mesa/glapi/glapitemp.h
+++ b/src/mesa/glapi/glapitemp.h
@@ -27,7 +27,7 @@
  */
 
 
-#  if defined(__GNUC__) || (defined(__SUNPRO_C) && (__SUNPRO_C >= 0x590))) && defined(__ELF__)
+#  if (defined(__GNUC__) || (defined(__SUNPRO_C) && (__SUNPRO_C >= 0x590))) && defined(__ELF__)
 #    define HIDDEN  __attribute__((visibility("hidden")))
 #  else
 #    define HIDDEN
diff --git a/src/mesa/main/compiler.h b/src/mesa/main/compiler.h
index 05e69e5..81704ae 100644
--- a/src/mesa/main/compiler.h
+++ b/src/mesa/main/compiler.h
@@ -173,7 +173,7 @@ extern "C" {
  * We also need to define a USED attribute, so the optimizer doesn't 
  * inline a static function that we later use in an alias. - ajax
  */
-#if defined(__GNUC__) || (defined(__SUNPRO_C) && (__SUNPRO_C >= 0x590)
+#if defined(__GNUC__) || (defined(__SUNPRO_C) && (__SUNPRO_C >= 0x590))
 #  define PUBLIC __attribute__((visibility("default")))
 #  define USED __attribute__((used))
 #else
-- 
1.7.0.1

[Mesa3d-dev] [Bug 26875] src/mesa/main/compiler.h:176:26: error: missing ')' in expression

[<bug...@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=26875


Thomas Anderson <neo...@ym...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #1 from Thomas Anderson <neo...@ym...>  2010-03-03 17:54:12 PST ---
(In reply to comment #0)
> Hi! Problem compiling mesa git master:
> 
> In file included from ../../src/mesa/main/mtypes.h:39,
>                  from main/api_arrayelt.h:31,
>                  from main/api_arrayelt.c:30:
> ../../src/mesa/main/compiler.h:176:26: error: missing ')' in expression
> In file included from ../main/mtypes.h:39,
>                  from gen_matypes.c:36:
> ../main/compiler.h:176:26: error: missing ')' in expression
> make[3]: *** [gen_matypes] Error 1
> make[3]: Leaving directory `/home/neo/mesa/src/mesa/x86'
> make[2]: *** [asm_subdirs] Error 1
> make[2]: *** Waiting for unfinished jobs....
> make[2]: *** [main/api_arrayelt.o] Error 1
> make[2]: Leaving directory `/home/neo/mesa/src/mesa'
> make[1]: *** [subdirs] Error 1
> make[1]: Leaving directory `/home/neo/mesa/src'
> make: *** [default] Error 1
> 
> If I did something wrong and this isn't valid, please let me know what I did
> wrong. Thank you.
> 

idr just fixed it. Thanks!


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Mesa3d-dev] [Bug 26875] New: src/mesa/main/compiler.h:176:26: error: missing ')' in expression

[<bug...@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=26875

           Summary: src/mesa/main/compiler.h:176:26: error: missing ')' in
                    expression
           Product: Mesa
           Version: git
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Other
        AssignedTo: mes...@li...
        ReportedBy: neo...@ym...


Hi! Problem compiling mesa git master:

In file included from ../../src/mesa/main/mtypes.h:39,
                 from main/api_arrayelt.h:31,
                 from main/api_arrayelt.c:30:
../../src/mesa/main/compiler.h:176:26: error: missing ')' in expression
In file included from ../main/mtypes.h:39,
                 from gen_matypes.c:36:
../main/compiler.h:176:26: error: missing ')' in expression
make[3]: *** [gen_matypes] Error 1
make[3]: Leaving directory `/home/neo/mesa/src/mesa/x86'
make[2]: *** [asm_subdirs] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: *** [main/api_arrayelt.o] Error 1
make[2]: Leaving directory `/home/neo/mesa/src/mesa'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/home/neo/mesa/src'
make: *** [default] Error 1

If I did something wrong and this isn't valid, please let me know what I did
wrong. Thank you.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Mesa3d-dev] writing line emulation for hw driver?

[<ran...@gm...>]

Hello all!

I recently plugged in old TNT2 (nv05) card and started to playing with it. 
This hardware can do quads and triangles, but not lines or points ....  So, i 
need to emulate them.

utah-glx has some code exactly for this generation of hardware:

http://utah-glx.cvs.sourceforge.net/viewvc/utah-glx/glx-xf3/servGL/hwglx/nv/riva_prim.c?revision=1.11&view=markup

I tried to  cook up something like this for current nouveau driver, but nearly 
failed.

Lack of hardware PolygonOffset support lead me into 
src/mesa/tnl_dd/t_dd_tritmp.h , used in many drivers. Currently, it can only 
DE-compose triangles, but can (or better - should) it be abjusted for 
creating additional vertex info (2->4, 1->4) ?

Should one still use this file in modern world? On non-hw-tcl capable hw ..... 

Re: [Mesa3d-dev] Does DX9 SM3 -> VMware svga with arbitrary semantics work? How?

[Roland S. <sr...@vm...>]

On 03.03.2010 20:23, Luca Barbieri wrote:
>> And never will...  It does not export PIPE_CAP_GLSL, and does not have
>> the shader opcodes to ever do so.
> 
> Any Gallium driver should be able to support the GLSL subset without
> control flow.
> 
> And if we had a proper optimization infrastructure capable of inlining
> functions, converting conditionals to multiplications and unrolling
> loops (e.g. look at what the nVidia Cg compiler does), then
> essentially all GLSL could be supported on any driver, with only
> limitations on the maximum number of loop iterations.
> 
> Isn't it worth supporting that?
> 
> BTW, proprietary drivers do this: for instance nVidia supports GLSL on
> nv30, which can't do control flow in fragment shaders and doesn't
> support SM3.

I think the i915 is a lot closer to r300 in that regard (which is quite
a bit more limited than nv30), and it's true that ATI also supported
glsl on that. As far as I know though it was quite easy to bump into
shaders which wouldn't compile. There's only so much you can do if you
have 4 blocks of (max) 16 instructions to run without any control flow
if you need to unroll loops, not to mention lacking instructions for
derivatives, or the fact things like sin/cos will take quite a few
instructions...
nv30, while processing fragment shaders slowly, had a LOT higher
instruction count, IIRC supported derivatives and predication and had no
dependent texturing limit. So that makes it a lot better suited for glsl
hacks.
So, I'm not sure it really makes a whole lot of sense to support glsl on
i915. It'll really only ever work for very simple things (granted there
are apps out there which indeed will only use glsl shaders which are
known to compile fine on r300...)

Roland

Re: [Mesa3d-dev] Does DX9 SM3 -> VMware svga with arbitrary semantics work? How?

[Keith W. <ke...@vm...>]

On Wed, 2010-03-03 at 06:58 -0800, Luca Barbieri wrote:
> BTW, i915 is also limited to 0-7 generic indices, and thus doesn't
> work with GLSL at all right now.
> 
> This should be relatively easy to fix since it should be enough to
> store the generic indices in the "texCoords" arrays, and then pass
> them to draw_find_shader_output.

Luca,

If you want to go ahead and send a patch, I don't have a problem with
it.  Like you say, it should be an easy change.

Keith

Re: [Mesa3d-dev] Does DX9 SM3 -> VMware svga with arbitrary semantics work? How?

[Keith W. <ke...@vm...>]

On Wed, 2010-03-03 at 11:23 -0800, Luca Barbieri wrote:
> > And never will...  It does not export PIPE_CAP_GLSL, and does not have
> > the shader opcodes to ever do so.
> 
> Any Gallium driver should be able to support the GLSL subset without
> control flow.
> 
> And if we had a proper optimization infrastructure capable of inlining
> functions, converting conditionals to multiplications and unrolling
> loops (e.g. look at what the nVidia Cg compiler does), then
> essentially all GLSL could be supported on any driver, with only
> limitations on the maximum number of loop iterations.
> 
> Isn't it worth supporting that?
> 
> BTW, proprietary drivers do this: for instance nVidia supports GLSL on
> nv30, which can't do control flow in fragment shaders and doesn't
> support SM3.

OK, maybe never is too strong...  But it's certainly a long way off...


Keith

Re: [Mesa3d-dev] Does DX9 SM3 -> VMware svga with arbitrary semantics work? How?

[Luca B. <lu...@lu...>]

> And never will...  It does not export PIPE_CAP_GLSL, and does not have
> the shader opcodes to ever do so.

Any Gallium driver should be able to support the GLSL subset without
control flow.

And if we had a proper optimization infrastructure capable of inlining
functions, converting conditionals to multiplications and unrolling
loops (e.g. look at what the nVidia Cg compiler does), then
essentially all GLSL could be supported on any driver, with only
limitations on the maximum number of loop iterations.

Isn't it worth supporting that?

BTW, proprietary drivers do this: for instance nVidia supports GLSL on
nv30, which can't do control flow in fragment shaders and doesn't
support SM3.

Re: [Mesa3d-dev] Does DX9 SM3 -> VMware svga with arbitrary semantics work? How?

[Keith W. <ke...@vm...>]

On Wed, 2010-03-03 at 06:58 -0800, Luca Barbieri wrote:
> BTW, i915 is also limited to 0-7 generic indices, and thus doesn't
> work with GLSL at all right now.

And never will...  It does not export PIPE_CAP_GLSL, and does not have
the shader opcodes to ever do so.

Keith

[Mesa3d-dev] [PATCH] st/vega: Fix OpenVG demo segfaults.

[<ol...@lu...>]

From: Chia-I Wu <ol...@lu...>

When the paint is color, paint_bind_samplers binds a dummy sampler
without a texture.  It causes demos requiring a sampler (those use a
mask or an image) to crash.
---
 src/gallium/state_trackers/vega/paint.c |    3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/src/gallium/state_trackers/vega/paint.c b/src/gallium/state_trackers/vega/paint.c
index caf0c14..cdb87d3 100644
--- a/src/gallium/state_trackers/vega/paint.c
+++ b/src/gallium/state_trackers/vega/paint.c
@@ -639,9 +639,6 @@ VGint paint_bind_samplers(struct vg_paint *paint, struct pipe_sampler_state **sa
    }
       break;
    default:
-      samplers[0] = &paint->pattern.sampler; /* dummy */
-      textures[0] = 0;
-      return 0;
       break;
    }
    return 0;
-- 
1.7.0

Re: [Mesa3d-dev] RFC: gallium-format-cleanup branch (was Gallium format swizzles)

[Roland S. <sr...@vm...>]

On 03.03.2010 14:07, José Fonseca wrote:
> On Wed, 2010-03-03 at 04:27 -0800, Luca Barbieri wrote:
>>> PIPE_FORMAT_X8B8G8R8_UNORM is being used by mesa.
>>> PIPE_FORMAT_R8G8B8X8_UNORM doesn't exist hence it appears to be
>>> unnecessary. So it doesn't make sense to rename.
>> How about D3DFMT_X8B8G8R8? That should map to
>> PIPE_FORMAT_R8G8B8X8_UNORM.
> 
> Yes, you're right.
> 
>> BTW, we are also missing D3DFMT_X4R4G4B4, D3DFMT_X1R5G5B5, 
>> D3DFMT_A4L4, D3DFMT_A1, D3DFMT_L6V5U5, D3DFMT_D15S1,
>> D3DFMT_D24X4S4, D3DFMT_CxV8U8 and perhaps others I did not notice.
> 
> D3DFMT_L6V5U5 is there (PIPE_FORMAT_R5SG5SB6U_NORM). The others are 
> indeed missing. Neither of the mentioned formats is required for D3D9
>  conformance, but we could add them to gallium.
> 
> D3DFMT_A1 is special: it has less than 1 byte per pixel. Probably the
>  best way to support it would be to treat it as a 8x1 macro pixel,
> 8bits, similarly to compressed formats.
> 
> D3DFMT_CxV8U8 too as special semantics.

And not only are those formats optional, some would be completely
pointless in gallium (D15S1, D24X4S4). There's simply no modern hardware
which supports 1 bit stencil (I think pretty much the only chip
supporting that was savage3d), nor 4 bit stencil (can't remember
off-hand any chip supporting that, maybe some of the then professional
chips did). The others sound a bit more plausible and hardware may
support them, but I'm not sure they are really missed (A4L4, X4R4G4B4,
X1R5G5B5). As José said, CxV8U8 isn't really a format only, and we'll
need to add 1-bit format for DX10.

Roland

Re: [Mesa3d-dev] Does DX9 SM3 -> VMware svga with arbitrary semantics work? How?

[Luca B. <lu...@lu...>]

BTW, i915 is also limited to 0-7 generic indices, and thus doesn't
work with GLSL at all right now.

This should be relatively easy to fix since it should be enough to
store the generic indices in the "texCoords" arrays, and then pass
them to draw_find_shader_output.

Re: [Mesa3d-dev] Does DX9 SM3 -> VMware svga with arbitrary semantics work? How?

[Olivier G. <gal...@po...>]

On Tue, Mar 02, 2010 at 09:43:51PM +0100, Luca Barbieri wrote:
> - Not sure about i965

On i965 interpolators are not a dedicated piece of hardware, they're
programs like the other shaders.  So the problem is entirely
different, and more at the level of space allocation in the
thread-to-thread communication packets in the pipeline vs. register
allocation in the shaders (there's a semi-direct mapping).

  OG.

Re: [Mesa3d-dev] Problem using an Mesa based App with recent xorg/mesa/xf86-video-intel (loop?)

[Michel D. <mi...@da...>]

On Wed, 2010-03-03 at 13:31 +0100, Simon Thum wrote: 
> 
> It then runs fine. I'm on radeon r200, but since my update yesterday
> (git master stack using gentoo overlay) I also have OpenGL problems,
> most notably, KWin 4.4's compositing doesn't work any more. Probably,
> this isn't just intel then.

If your mesa Git checkout doesn't have commit
5f40a7aed12500fd6792e2453f495555c3b5c54d yet, try updating again.

Anyway, I think it's unlikely your problem is the same.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer