mesa3d-dev

[Mesa3d-dev] [Bug 27312] glCopyTexImage2D Doesnt seem to work correctly (returns incorrect alpha component )when internal format is GL_RGB

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

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





--- Comment #5 from Karthik Hariharakrishnan <kar...@ar...>  2010-03-26 10:44:59 PST ---
Created an attachment (id=34495)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=34495)
header file included from source


-- 
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 27312] glCopyTexImage2D Doesnt seem to work correctly (returns incorrect alpha component )when internal format is GL_RGB

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

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





--- Comment #4 from Karthik Hariharakrishnan <kar...@ar...>  2010-03-26 10:44:37 PST ---
Created an attachment (id=34494)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=34494)
Source code for reproducing the problem. 


-- 
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 27254] glBlitFramebuffer is defined while glBlitFramebufferEXT is hidden as described by the XMLs

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

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


Ian Romanick <id...@fr...> changed:

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




--- Comment #5 from Ian Romanick <id...@fr...>  2010-03-26 09:49:15 PST ---
(In reply to comment #4)
> I think I should brought this up since 7.8 is about to be released.  In
> gl_API.xml, we have
> 
>   <function name="HistogramEXT" alias="Histogram" static_dispatch="false">
> 
> C and X86-64 dispatcher correctly hide glHistogramEXT.  However, up until
> recently, X86 dispatcher exposed the function.  I've made a commit
> 
>   41a87a43e11c664935349f938022d58d3e22da4e
> 
> to honor gl_API.xml and hide the symbol (and some others).  Does this sound
> fine to your or is this considered an ABI breakage?

Sorry for the slowness of my reply.  As long as the set of symbols exposed on
x86 isn't reduced to less than the set of symbols exposed on x86-64, I think
the change should be fine.

Since the original report wasn't actually a bug in Mesa, I'm going to close
this as NOTABUG.


-- 
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 27312] glCopyTexImage2D Doesnt seem to work correctly (returns incorrect alpha component )when internal format is GL_RGB

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

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





--- Comment #3 from Karthik Hariharakrishnan <kar...@ar...>  2010-03-26 09:22:01 PST ---
(In reply to comment #2)
> Which driver are you using?  swrast or softpipe or other?
> 
> I could probably look into this as soon as you provide a (glut) test program.
> 

Hi,

 I am using the egl driver for window management. I built egl_softpipe.so in
src/gallium/winsys/egl_xlib. And am linking with the gallium libraries. I will
try uploading the source file soon. 


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

Re: [Mesa3d-dev] [PATCH] glGet: Optimize glGet calls by avoiding redundant state updates

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

Following up on an message from a while ago:

Brian Paul wrote:
> Robert Bragg wrote:
>> Hi,
>>
>> Every now and then while working on the Clutter toolkit we end up with
>> glGet{Integer,Float}v in our profiles. Our typical response is to simply
>> cache the offending state so as to avoid querying OpenGL, but it feels
>> like this is papering over the problem.
>> I've attached a patch that instead tries to address the performance
>> problem in Mesa and hoping something like this could be accepted
>> upstream?
> 
> Coincidentally, I was looking at this just recently.
> 
> It would be a good change to make.  Though I think I'd add a new flag to 
> the StateVars table entries to indicate whether the state requires 
> validation (and what state).  Then auto-generate the needed code.
> 
> So GL_RED_BITS case would be predicated like this:
> 
>    case GL_RED_BITS:
>       if (ctx->NewState & _NEW_BUFFERS)
>          _mesa_update_state(ctx);
>       params[0] = ctx->DrawBuffer->Visual.redBits;
>       break;
> 
> _NEW_BUFFERS would be a new field in the StateVars list.
> 
> 
> Most state queries don't need validation.  The ones that do are the ones 
> that you patched plus the "current" attribs (_NEW_CURRENT_ATTRIB).  
> Maybe a few others?
> 
> Are you interested in coding this up?

I've implemented change this and will be committing it soon.

-Brian

[Mesa3d-dev] [Bug 27300] r300_fs.c:209: r300_translate_fragment_shader: Assertion `0' failed.

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

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





--- Comment #5 from Darren Salt <li...@yo...>  2010-03-26 08:31:41 PST ---
About compiling Oolite: "make -f Makefile pkg-deb" works here. ("debuild
binary" would be fine, but debian/changelog is generated.)

http://www.oolite.org/download has links to binaries.


-- 
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 27300] r300_fs.c:209: r300_translate_fragment_shader: Assertion `0' failed.

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

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





--- Comment #4 from Darren Salt <li...@yo...>  2010-03-26 08:21:21 PST ---
Created an attachment (id=34486)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=34486)
Shader log from Oolite

One log file, as requested. (This is with shader-effects-level set to 3.)


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

Re: [Mesa3d-dev] Build Error with Xorg State Tracker

[Dan N. <dbn...@gm...>]

On Wed, Mar 24, 2010 at 07:00:06AM -0700, STEVE555 wrote:
> 
> Dear Jakob,
>                  I did a ./autogen.sh and Mesa builds fine now,sorry about
> that.I do run ./autogen.sh from time to time,I just thought ./configure
> would be enough,oh well,I like to thank you for your help.

When someone makes a commit to configure.ac, the configure file has to
be regenerated. Usually automake adds rules so that if configure.ac is
newer than configure, it runs autoconf again. We can try to add some
rules like that to the toplevel Makefile, but I'd like to take a look at
the way automake does it before adding some half baked hack.

However, the takeaway is that if you're seeing build errors, you'll want
to check that configure is up to date and that it's been run again.

Here's a handy trick for regenerating the autotools and keeping your
configure arguments:

$ autoreconf -iv && ./config.status --recheck && ./config.status

That's pretty much a surefire way to ensure the autotools (whichever
ones) are refreshed, and the second part runs configure again with your
arguments you used before.

--
Dan

Re: [Mesa3d-dev] [PATCH] add r200-swtnl-material-fallback test case

[Pauli N. <su...@gm...>]

On Sun, Mar 21, 2010 at 8:02 PM, Pauli Nieminen <su...@gm...> wrote:
> There is bug in r200 swtnl fallback that hwtnl state is emited in swtnl flush.
> Bug causes emit size to be larger that excepted which might cause crash in some
> corner cases.
>
> Signed-off-by: Pauli Nieminen <su...@gm...>
> ---
>  tests/all.tests                           |    1 +
>  tests/bugs/CMakeLists.txt                 |    1 +
>  tests/bugs/r200-swtnl-material-fallback.c |   79 +++++++++++++++++++++++++++++
>  3 files changed, 81 insertions(+), 0 deletions(-)
>  create mode 100644 tests/bugs/r200-swtnl-material-fallback.c
>
> diff --git a/tests/all.tests b/tests/all.tests
> index d42de3b..afb0cb6 100644
> --- a/tests/all.tests
> +++ b/tests/all.tests
> @@ -241,6 +241,7 @@ add_plain_test(bugs, 'fdo10370')
>  add_plain_test(bugs, 'fdo14575')
>  add_plain_test(bugs, 'fdo20701')
>  add_plain_test(bugs, 'r300-readcache')
> +add_plain_test(bugs, 'r200-swtnl-material-fallback')
>  add_plain_test(bugs, 'tex1d-2dborder')
>  add_plain_test(bugs, 'point-sprite')
>  add_plain_test(bugs, 'fdo22540')
> diff --git a/tests/bugs/CMakeLists.txt b/tests/bugs/CMakeLists.txt
> index 3a72a96..de5ac5d 100644
> --- a/tests/bugs/CMakeLists.txt
> +++ b/tests/bugs/CMakeLists.txt
> @@ -35,3 +35,4 @@ add_executable (fdo23670-depth_test fdo23670-depth_test.c)
>  add_executable (fdo23670-drawpix_stencil fdo23670-drawpix_stencil.c)
>  add_executable (fdo24066 fdo24066.c)
>  add_executable (fdo25614-genmipmap fdo25614-genmipmap.c)
> +add_executable (r200-swtnl-material-fallback r200-swtnl-material-fallback.c)
> diff --git a/tests/bugs/r200-swtnl-material-fallback.c b/tests/bugs/r200-swtnl-material-fallback.c
> new file mode 100644
> index 0000000..4cc22d8
> --- /dev/null
> +++ b/tests/bugs/r200-swtnl-material-fallback.c
> @@ -0,0 +1,79 @@
> +/*
> + * Copyright © 2010 Pauli Nieminen
> + *
> + * 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 without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * 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 NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR 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.
> + */
> +
> +/**
> + * Check that r200 swtnl fallback return doesn't emit hwtnl state.
> + *
> + * \author Pauli Nieminen
> + */
> +
> +
> +#include "piglit-util.h"
> +
> +int piglit_width = 100;
> +int piglit_height = 100;
> +int piglit_window_mode = GLUT_RGB | GLUT_DOUBLE;
> +
> +void
> +piglit_init(int argc, char **argv)
> +{
> +       piglit_ortho_projection(piglit_width, piglit_height, GL_FALSE);
> +       glClearColor(0.0, 0.0, 0.0, 0.0);
> +}
> +
> +enum piglit_result
> +piglit_display(void)
> +{
> +       static GLfloat excepted[][3] = {
> +               {0.2,0.0,0.0},
> +               {0.2,0.2,0.2},
> +       };
> +       static GLfloat mat[][4] = {
> +               {1.0,0.0,0.0,0.0},
> +               {1.0,1.0,1.0,0.0},
> +       };
> +
> +       GLboolean pass = GL_TRUE;
> +       glClear(GL_COLOR_BUFFER_BIT);
> +       glEnable(GL_LIGHTING);
> +
> +       glBegin(GL_TRIANGLE_STRIP);
> +
> +       glMaterialfv(GL_FRONT_AND_BACK, GL_AMBIENT_AND_DIFFUSE, mat[0]);
> +       glVertex3f((GLfloat)piglit_height, 0.0, 0.0);
> +       glVertex3f(0.0, 0.0, 0.0);
> +       glVertex3f((GLfloat)piglit_height, (GLfloat)piglit_width, 0.0);
> +       glMaterialfv(GL_FRONT_AND_BACK, GL_AMBIENT_AND_DIFFUSE, mat[1]);
> +       glVertex3f(0.0, (GLfloat) piglit_width, 0.0);
> +
> +       glEnd();
> +
> +       if (!piglit_probe_pixel_rgb(piglit_width - 1, 1, excepted[0]))
> +               pass = GL_FALSE;
> +       if (!piglit_probe_pixel_rgb(1, piglit_height - 1, excepted[1]))
> +               pass = GL_FALSE;
> +
> +       glutSwapBuffers();
> +
> +       return pass ? PIGLIT_SUCCESS : PIGLIT_FAILURE;
> +}
> --
> 1.6.3.3
>
>

I pushed change to my personal git repository.
Can someone pull it and commit to piglit?
git pull git://anongit.freedesktop.org/~suokko/piglit.git master

[Mesa3d-dev] [Bug 27300] r300_fs.c:209: r300_translate_fragment_shader: Assertion `0' failed.

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

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





--- Comment #3 from Corbin Simpson <Mos...@gm...>  2010-03-26 05:40:07 PST ---
Can't figure out how to build your program. :T

You hit the generic "error in shader compiler" assert. Could you run again with
RADEON_DEBUG=fp set, and attach that log here?


-- 
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 27300] r300_fs.c:209: r300_translate_fragment_shader: Assertion `0' failed.

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

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





--- Comment #2 from Corbin Simpson <Mos...@gm...>  2010-03-26 04:57:09 PST ---
Tired, commented on wrong bug. Investigating yours now.


-- 
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 27300] r300_fs.c:209: r300_translate_fragment_shader: Assertion `0' failed.

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

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


Corbin Simpson <Mos...@gm...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED




--- Comment #1 from Corbin Simpson <Mos...@gm...>  2010-03-26 04:33:35 PST ---
Reverting cba6430524198a1bdcdeada03cbe946a454f3935 stops the hardlock, but now
there's a failing vertex shader. Looking into it now.


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

Re: [Mesa3d-dev] New buuild error with Mesa git

[Jakob B. <wal...@gm...>]

On Fri, Mar 26, 2010 at 9:36 AM, Xavier Chantry
<cha...@gm...> wrote:
> On Fri, Mar 26, 2010 at 2:51 AM, STEVE555 <ste...@ho...> wrote:
>>
>> Hi guys,
>>            I've pulled in the latest commits from Mesa git at about 1am
>> this morning.
>> I ran gmake -B realclean,and then used autoreconf -iv and ./autogen.sh with
>> my configure options,i.e:
>>
>> ./autogen.sh --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 --enable-debug
>>
>> I get this new error after gmake gets to the vmgfx-state-tracker:
>>
>> ommon/dri_util.c -o ../../../../src/mesa/drivers/dri/common/dri_util.o
>> gcc -c -I. -I../../../../src/mesa/drivers/dri/common -Iserver
>> -I../../../../include -I../../../../include/GL/internal
>> -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary
>> -I../../../../src/gallium/drivers -I../../../../src/gallium/winsys/common
>> -I../../../../src/mesa -I../../../../src/mesa/main
>> -I../../../../src/mesa/glapi -I../../../../src/mesa/math
>> -I../../../../src/mesa/transform -I../../../../src/mesa/shader
>> -I../../../../src/mesa/swrast -I../../../../src/mesa/swrast_setup
>> -I../../../../src/egl/main -I../../../../src/egl/drivers/dri
>> -I/usr/include/libdrm   -I/usr/lib/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
>> ../../../../src/mesa/drivers/dri/common/xmlconfig.c -o
>> ../../../../src/mesa/drivers/dri/common/xmlconfig.o
>> gmake[3]: *** No rule to make target
>> `../../../../src/gallium/drivers/svga/libsvga.a', needed by `vmwgfx_dri.so'.
>> Stop.
>> gmake[3]: Leaving directory `/opt/mesa/src/gallium/targets/dri-vmwgfx'
>> gmake[2]: *** [default] Error 1
>> gmake[2]: Leaving directory `/opt/mesa/src/gallium/targets'
>> gmake[1]: *** [subdirs] Error 1
>> gmake[1]: Leaving directory `/opt/mesa/src'
>> gmake: *** [default] Error
>>
>> I've ran gmake -B realcean and ./autogen.sh twice,but I keep hitting the
>> same error.
>> Regards,
>>             STEVE555
>
> It's just a small typo in a82e37b9e9e34175b7542d0c9b4e462833eab202
> gallium: Add propper sanity checks in configure.ac
>
> Try this patch (easy to apply by hand) :
>
> diff --git a/configure.ac b/configure.ac
> index caa2cf6..f2e87f4 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1344,7 +1344,7 @@ AC_ARG_ENABLE([gallium-svga],
>     [enable_gallium_svga="$enableval"],
>     [enable_gallium_svga=auto])
>  if test "x$enable_gallium_svga" = xyes; then
> -    GALLIUM_DRIVERS_DIRS="$GALLIUM_DRIVERS_DIRS svga/drm"
> +    GALLIUM_DRIVERS_DIRS="$GALLIUM_DRIVERS_DIRS svga"
>     gallium_check_st "svga/drm" "dri-vmwgfx" "egl-vmwgfx" "xorg-vmwgfx"
>  elif test "x$enable_gallium_svga" = xauto; then
>     GALLIUM_DRIVERS_DIRS="$GALLIUM_DRIVERS_DIRS svga"

Ops. Thanks for the fix. I have pushed the fix to master.

Cheers Jakob.

Re: [Mesa3d-dev] [RFC] gallium-targets merge

[Jakob B. <wal...@gm...>]

On Fri, Mar 26, 2010 at 9:57 AM, Xavier Chantry
<cha...@gm...> wrote:
> On Thu, Mar 25, 2010 at 8:32 PM, Jakob Bornecrantz <wal...@gm...> wrote:
>>
>> Thanks again for testing.
>>
>> Okay, this could be solved by just checking if the state trackers are
>> built where we enable the the targets instead of the subsystem or
>> driver. The xorg drivers is the only one doing this correctly, by
>> checking HAVE_XORG.
>>
>> I'll get to that later today.
>>
>
> It's perfect now, thanks. And I like the refactoring and better consistency.
>
> STEVE555 reported a build failure in another thread with svga, it
> seems to just be a small typo.
>

Thanks, have pushed a fix.

Cheers Jakob.

Re: [Mesa3d-dev] [RFC] gallium-targets merge

[Xavier C. <cha...@gm...>]

On Thu, Mar 25, 2010 at 8:32 PM, Jakob Bornecrantz <wal...@gm...> wrote:
>
> Thanks again for testing.
>
> Okay, this could be solved by just checking if the state trackers are
> built where we enable the the targets instead of the subsystem or
> driver. The xorg drivers is the only one doing this correctly, by
> checking HAVE_XORG.
>
> I'll get to that later today.
>

It's perfect now, thanks. And I like the refactoring and better consistency.

STEVE555 reported a build failure in another thread with svga, it
seems to just be a small typo.

Re: [Mesa3d-dev] New buuild error with Mesa git

[Xavier C. <cha...@gm...>]

On Fri, Mar 26, 2010 at 2:51 AM, STEVE555 <ste...@ho...> wrote:
>
> Hi guys,
>            I've pulled in the latest commits from Mesa git at about 1am
> this morning.
> I ran gmake -B realclean,and then used autoreconf -iv and ./autogen.sh with
> my configure options,i.e:
>
> ./autogen.sh --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 --enable-debug
>
> I get this new error after gmake gets to the vmgfx-state-tracker:
>
> ommon/dri_util.c -o ../../../../src/mesa/drivers/dri/common/dri_util.o
> gcc -c -I. -I../../../../src/mesa/drivers/dri/common -Iserver
> -I../../../../include -I../../../../include/GL/internal
> -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary
> -I../../../../src/gallium/drivers -I../../../../src/gallium/winsys/common
> -I../../../../src/mesa -I../../../../src/mesa/main
> -I../../../../src/mesa/glapi -I../../../../src/mesa/math
> -I../../../../src/mesa/transform -I../../../../src/mesa/shader
> -I../../../../src/mesa/swrast -I../../../../src/mesa/swrast_setup
> -I../../../../src/egl/main -I../../../../src/egl/drivers/dri
> -I/usr/include/libdrm   -I/usr/lib/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
> ../../../../src/mesa/drivers/dri/common/xmlconfig.c -o
> ../../../../src/mesa/drivers/dri/common/xmlconfig.o
> gmake[3]: *** No rule to make target
> `../../../../src/gallium/drivers/svga/libsvga.a', needed by `vmwgfx_dri.so'.
> Stop.
> gmake[3]: Leaving directory `/opt/mesa/src/gallium/targets/dri-vmwgfx'
> gmake[2]: *** [default] Error 1
> gmake[2]: Leaving directory `/opt/mesa/src/gallium/targets'
> gmake[1]: *** [subdirs] Error 1
> gmake[1]: Leaving directory `/opt/mesa/src'
> gmake: *** [default] Error
>
> I've ran gmake -B realcean and ./autogen.sh twice,but I keep hitting the
> same error.
> Regards,
>             STEVE555

It's just a small typo in a82e37b9e9e34175b7542d0c9b4e462833eab202
gallium: Add propper sanity checks in configure.ac

Try this patch (easy to apply by hand) :

diff --git a/configure.ac b/configure.ac
index caa2cf6..f2e87f4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1344,7 +1344,7 @@ AC_ARG_ENABLE([gallium-svga],
     [enable_gallium_svga="$enableval"],
     [enable_gallium_svga=auto])
 if test "x$enable_gallium_svga" = xyes; then
-    GALLIUM_DRIVERS_DIRS="$GALLIUM_DRIVERS_DIRS svga/drm"
+    GALLIUM_DRIVERS_DIRS="$GALLIUM_DRIVERS_DIRS svga"
     gallium_check_st "svga/drm" "dri-vmwgfx" "egl-vmwgfx" "xorg-vmwgfx"
 elif test "x$enable_gallium_svga" = xauto; then
     GALLIUM_DRIVERS_DIRS="$GALLIUM_DRIVERS_DIRS svga"

Re: [Mesa3d-dev] Current tinderbox regression (swrastg_dri, sparc64)

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

On Fri, Mar 26, 2010 at 4:11 AM, Luca Barbieri <luc...@gm...> wrote:
> Are you sure that swrastg and/or any Gallium driver actually load
> correctly and work on sparc64?
>

you are right, I forgot that gallium has its own sync primitives,
scratch my reply

> This seems to indicate that they use __sync_add_and_fetch_4 assuming
> it is a GCC builtin, but GCC does not implement it as a builtin on
> sparc64 and neither libgcc nor libc have an implementation of the
> function.
>
> I don't know anything about sparc64, but according to the linux
> kernel, I vaguely guess that specifying an high enough -march= to gcc
> could solve it by enabling use of atomic instructions that are
> otherwise are not used.
>
> The root cause is likely that we set PIPE_ATOMIC_GCC_INTRINSIC even
> though not all __sync builtins are actually supported: we should
> probably fix that.
>

Re: [Mesa3d-dev] Current tinderbox regression (swrastg_dri, sparc64)

[Luca B. <luc...@gm...>]

Are you sure that swrastg and/or any Gallium driver actually load
correctly and work on sparc64?

This seems to indicate that they use __sync_add_and_fetch_4 assuming
it is a GCC builtin, but GCC does not implement it as a builtin on
sparc64 and neither libgcc nor libc have an implementation of the
function.

I don't know anything about sparc64, but according to the linux
kernel, I vaguely guess that specifying an high enough -march= to gcc
could solve it by enabling use of atomic instructions that are
otherwise are not used.

The root cause is likely that we set PIPE_ATOMIC_GCC_INTRINSIC even
though not all __sync builtins are actually supported: we should
probably fix that.

[Mesa3d-dev] New buuild error with Mesa git

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

Hi guys,
            I've pulled in the latest commits from Mesa git at about 1am
this morning.
I ran gmake -B realclean,and then used autoreconf -iv and ./autogen.sh with
my configure options,i.e:

./autogen.sh --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 --enable-debug

I get this new error after gmake gets to the vmgfx-state-tracker:

ommon/dri_util.c -o ../../../../src/mesa/drivers/dri/common/dri_util.o
gcc -c -I. -I../../../../src/mesa/drivers/dri/common -Iserver
-I../../../../include -I../../../../include/GL/internal
-I../../../../src/gallium/include -I../../../../src/gallium/auxiliary
-I../../../../src/gallium/drivers -I../../../../src/gallium/winsys/common
-I../../../../src/mesa -I../../../../src/mesa/main
-I../../../../src/mesa/glapi -I../../../../src/mesa/math
-I../../../../src/mesa/transform -I../../../../src/mesa/shader
-I../../../../src/mesa/swrast -I../../../../src/mesa/swrast_setup
-I../../../../src/egl/main -I../../../../src/egl/drivers/dri
-I/usr/include/libdrm   -I/usr/lib/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 
../../../../src/mesa/drivers/dri/common/xmlconfig.c -o
../../../../src/mesa/drivers/dri/common/xmlconfig.o
gmake[3]: *** No rule to make target
`../../../../src/gallium/drivers/svga/libsvga.a', needed by `vmwgfx_dri.so'. 
Stop.
gmake[3]: Leaving directory `/opt/mesa/src/gallium/targets/dri-vmwgfx'
gmake[2]: *** [default] Error 1
gmake[2]: Leaving directory `/opt/mesa/src/gallium/targets'
gmake[1]: *** [subdirs] Error 1
gmake[1]: Leaving directory `/opt/mesa/src'
gmake: *** [default] Error 

I've ran gmake -B realcean and ./autogen.sh twice,but I keep hitting the
same error.
Regards,
             STEVE555
-- 
View this message in context: http://old.nabble.com/New-buuild-error-with-Mesa-git-tp28037419p28037419.html
Sent from the mesa3d-dev mailing list archive at Nabble.com.

Re: [Mesa3d-dev] Current tinderbox regression (swrastg_dri, sparc64)

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

On Fri, Mar 26, 2010 at 2:23 AM, Chris Ball <cj...@la...> wrote:
> Hi,
>
> http://tinderbox.x.org/builds/2010-03-25-0018/logs/libGL/#build
>
> mklib: Making Linux shared library:  swrastg_dri.so.tmp
> gcc -o swrastg_dri.so.test ../../../../src/mesa/drivers/dri/common/dri_test.o swrastg_dri.so.tmp
> -L/home/cjb/xorg-build/lib -ldrm   -lexpat -lm -lpthread -ldl
> swrastg_dri.so.tmp: undefined reference to `__sync_sub_and_fetch_4'
> swrastg_dri.so.tmp: undefined reference to `__sync_add_and_fetch_4'
>
> (Only seen on sparc64.)
>

my guess is that glapi uses sync primitives (see glthread.h) and the
test is done against stubs which does not contain these primitives.

it should be possible to build the real libglapi.a first (by adding a
Makefile in src/mesa/glapi) and then do the link test using the real
libglapi.a

Re: [Mesa3d-dev] [RFC] Draw module patch and BGRA fix for i915g

[Jakob B. <wal...@gm...>]

On Thu, Mar 25, 2010 at 11:52 PM, Brian Paul <br...@vm...> wrote:
> Jakob Bornecrantz wrote:
>>
>> Hi Brian, Keith, Zack et al.
>>
>> So I tried to get i915g running again and it looks like there is a
>> RGBA vs BGRA bug in the draw module. I have attached two patches that
>> I would like to have some comments on before commit.
>>
>> Patch 1 removes a bunch of switch cases that was strew all over the
>> draw module that all pretty much did exactly the same thing. Which
>> made it hard to fix the RGBA issue for i915g. In draw_pipe_vbuf and
>> draw_pt_emit the format for EMIT_4UB was one thing and in
>> draw_pt_fetch_emit it was another. In light of the format clean up I
>> standardized on following the same as the float formats for EMIT_4UB.
>>
>> Patch 2 then introduces EMIT_4UB_BGRA and is used by i915g to make the
>> colors look correct again.
>>
>> Comments please.
>>
>> Cheers Jakob.
>>
>
>
> The new translsation function:
>
> static INLINE unsigned draw_translate_vinfo_format_size(unsigned format)
>
> and the existing:
>
> static INLINE unsigned draw_translate_vinfo_format(unsigned format )
>
> should probably both take a 'enum attrib_emit' instead of unsigned int.

Done.

>
> Also, the default switch cases should probably have an assert(0 &&
> "unexpected format") in case someone were to add a new format value but
> forget to update the helper functions.

Done.

>
> Looks good otherwise.

Thanks for the review, pushed to master.

Cheers Jakob.

[Mesa3d-dev] Current tinderbox regression (swrastg_dri, sparc64)

[Chris B. <cj...@la...>]

Hi,

http://tinderbox.x.org/builds/2010-03-25-0018/logs/libGL/#build

mklib: Making Linux shared library:  swrastg_dri.so.tmp
gcc -o swrastg_dri.so.test ../../../../src/mesa/drivers/dri/common/dri_test.o swrastg_dri.so.tmp
-L/home/cjb/xorg-build/lib -ldrm   -lexpat -lm -lpthread -ldl
swrastg_dri.so.tmp: undefined reference to `__sync_sub_and_fetch_4'
swrastg_dri.so.tmp: undefined reference to `__sync_add_and_fetch_4'

(Only seen on sparc64.)

-- 
Chris Ball   <cj...@la...>
One Laptop Per Child

[Mesa3d-dev] [Bug 27286] Mod function returns wrong value

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

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





--- Comment #5 from Brian Paul <bri...@gm...>  2010-03-25 17:23:47 PST ---
Off-hand, I _think_ this is an issue with the SSE rcp (reciprocol) instruction.
 Per the comment in the code, I think we need to produce a more accurate
result:

static void
emit_rcp (
   struct x86_function *func,
   unsigned xmm_dst,
   unsigned xmm_src )
{
   /* On Intel CPUs at least, this is only accurate to 12 bits -- not
    * good enough.  Need to either emit a proper divide or use the
    * iterative technique described below in emit_rsqrt().
    */
   sse2_rcpps(
      func,
      make_xmm( xmm_dst ),
      make_xmm( xmm_src ) );
}

Maybe someone handier with SSE can try to fix this.  The emit_rsqrt() function
further down uses a Newton-Raphson step to improve the results.  That could
help.


-- 
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 27312] glCopyTexImage2D Doesnt seem to work correctly (returns incorrect alpha component )when internal format is GL_RGB

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

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





--- Comment #2 from Brian Paul <bri...@gm...>  2010-03-25 17:17:14 PST ---
Which driver are you using?  swrast or softpipe or other?

I could probably look into this as soon as you provide a (glut) test program.


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

Re: [Mesa3d-dev] plumbing for gallium swrast_dri.so

[Jakob B. <wal...@gm...>]

On Thu, Mar 25, 2010 at 11:22 PM, George Sapountzis
<gsa...@gm...> wrote:
> On Thu, Mar 25, 2010 at 9:49 PM, Jakob Bornecrantz <wal...@gm...> wrote:
>> On Thu, Mar 25, 2010 at 7:00 PM, George Sapountzis
>> <gsa...@gm...> wrote:
>>> On Thu, Mar 25, 2010 at 7:58 PM, Jakob Bornecrantz <wal...@gm...> wrote:
>>>> 0003 moves drisw into dri/sw and the drm dri files into dri/drm, yet
>>>> again for clarity.
>>>>
>>>> 0004 moves the common files into a common directory.
>>>>
>>>
>>> I think that it may be better to just consolidate dri_screen.c /
>>> dri_context.c / dri_drawable.c / dri_extension.c in a single file
>>> named dri.c or dri_api.c or dri_driver_api.c similar to the glx/xlib
>>> state_tracker. There is not much left in the above files after
>>> splitting out version-specific code.
>>>
>>> Then you will have:
>>> dri_api.c or dri_driver_api.c for the DRI "window system" binding
>>> dri_st_api.c
>>> and
>>> dri1.c dri2.c drisw.c for the different versions
>>>
>>> the only outlier is dri1_helper which I agree may have a better name.
>>>
>>> But then I looked at this a lot lately and your suggestion may be
>>> better for someone looking at it after some time.
>>
>> I think you can do both, the moving of the files is more for making it
>> blatantly clear what is going on. The common files live in the common
>> directory and the rest are in their own directory. This mirrors what
>> is done in egl.
>>
>> I'm ambivalent about grouping the files together. And I don't think
>> that moving them it a common directory stops us from doing either one.
>> Then again dri_extension.c is quite useless, and should probably be
>> moved into dri_screen either way.
>>
>> Are you strongly against the layout that I suggested? I have no real
>> problem with doing both?
>>
>
> Ah ok, then the suggested layout serves well its purpose. Wrt to
> consilidating in dri_driver_api.c (dri_util.c is effectively
> dri_api.c), it depends on what your plans are for st/dri and if it
> involves adding more common code, I don't have other plans for st/dri
> :-)

Thanks, pushed.

I don't know, I thought about trying to add EGL Image support to
st/dri once it lands in st_api.h and st/egl.

And thinking about it I'm leaning more towards keeping them separated.
This is the traditionalist in me speaking, keeping code related to one
object in each file (screen, context, drawable). This keeps things in
line with the rest of the traditional dri drivers. We could merge in
dri_extensions.c into dri_context.c and dri_st_api.c into
dri_drawable.c and dri_screen.c, if it is the amount of files that you
are worried about (in fact I prefer that over just keeping at as it
is).

Also I files above 1k loc board always feels a bit intimating :-).

Then again this is not a strong feeling, so if you have strong
opinions or it hampers your development please go ahead and change.
Some improvement should be made tho.

>
> I'll add a comment about the ifdef's (srceen / swap_buffers in
> dri_screen.c, flush_front / alloc_buffers in dri_st_api.c) and to
> drisw_util.h about its relationship to dri_util.h .
>
>>>
>>>> One thing that could be done to reduce the amount of #ifdefs would be
>>>> to move the tables from dri_screen.c into drisw.c and dri2.c.
>>>
>>> yes, this could be done unless the suggestion above is adopted, in
>>> which case I thinks it's probably better to keep all the dri_
>>> functions static and the _DriverAPI tables in the common file.
>>
>> There is only one function that is static that is used in the tables,
>> or are you meaning that we should make them static as we move all of
>> them into a single file?
>>
>
> yes, if we move them all to dri_driver_api.c then it makes more sense
> to make them static and keep _DriverAPI in dri_driver_api.c with an
> ifdef.
>

With the -fvisibility=invisible flag given to gcc all those symbols
are pretty much static. Again not strong opinions.

Thanks again for the work you did.

Cheers Jakob.