mesa3d-dev

Re: [Mesa3d-dev] [PATCH] Fix --enable-32-bit: honor -m32 for progs/glsl.

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

2010/2/25 Török Edvin <edw...@gm...>:
> ---
>  progs/glsl/Makefile |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/progs/glsl/Makefile b/progs/glsl/Makefile
> index 8928c83..aaa54cb 100644
> --- a/progs/glsl/Makefile
> +++ b/progs/glsl/Makefile
> @@ -16,7 +16,7 @@ LIBS = -L$(TOP)/$(LIB_DIR) -l$(GLUT_LIB) -l$(GLEW_LIB) -l$(GLU_LIB) \
>  # using : to avoid APP_CC pointing to CC loop
>  CC := $(APP_CC)
>  CFLAGS := -I$(INCDIR) $(CFLAGS)
> -LDLIBS = $(LIBS)
> +LDLIBS = $(LIBS) $(ARCH_FLAGS)

Can you show the error you're getting? This should already be handled
in CFLAGS, but I suspect using make's implicit rules is causing this
problem.

--
Dan

Re: [Mesa3d-dev] Patch for eglplatform.h

[Daniel S. <da...@fo...>]

Hi,

On Fri, Feb 26, 2010 at 07:31:07AM +0100, Tom Cooksey wrote:
> With the attached patch applied, I can build Qt against Mesa's EGL &
> GLES2 libraries as they currently stand in master. What's more,
> examples/opengl/hellogl_es2 runs perfectly against the gallium swrast
> driver. The i965 driver was less successful however (my X server
> died). :-/
> 
> Dunno if people will agree with the patch, but I'd imagine it's not
> just Qt which will have problems with egl including X11 headers?

Doesn't Qt already have guards for X definitions such as Display, Pixmap
and Window?

> --- a/include/EGL/eglplatform.h
> +++ b/include/EGL/eglplatform.h
> @@ -80,13 +80,9 @@ typedef void *EGLNativePixmapType;
>  
>  #elif defined(__unix__) || defined(__unix)
>  
> -/* X11 (tentative)  */
> -#include <X11/Xlib.h>
> -#include <X11/Xutil.h>
> -
> -typedef Display *EGLNativeDisplayType;
> -typedef Pixmap   EGLNativePixmapType;
> -typedef Window   EGLNativeWindowType;
> +typedef struct _XDisplay *EGLNativeDisplayType;
> +typedef unsigned long     EGLNativePixmapType;
> +typedef unsigned long     EGLNativeWindowType;

In any case, you might as well just call the native display type void *.

Cheers,
Daniel

[Mesa3d-dev] [Bug 26768] New: Segmentation fault with indirect rendering

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

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

           Summary: Segmentation fault with indirect rendering
           Product: Mesa
           Version: 7.6
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: major
          Priority: medium
         Component: GLX
        AssignedTo: mes...@li...
        ReportedBy: mar...@x-...


When using indirect rendering and the program "framebufferobject" from the Qt
demos a segmentation fault happens.

The segmentation fault is in src/glx/x11/indirect_vertex_array.c:
__glXPushArrayState(), because glPushClientAttrib(GL_CLIENT_VERTEX_ARRAY_BIT)
is called twice or more times.

The solution is to change src/glx/x11/indirect_vertex_array.c, line 293
(function glXInitVertexArrayState) from:

  arrays->stack = malloc(sizeof(struct array_stack_state)
                          * arrays->num_arrays);

to:

   arrays->stack = malloc( sizeof( struct array_stack_state )
                            * arrays->num_arrays
*__GL_CLIENT_ATTRIB_STACK_DEPTH);


-- 
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] fix test progs from gl_API move

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

On Thu, 2010-02-25 at 21:00 -0800, Wil Reichert wrote: 
> Looks like these got missed.

Pushed along with some further related fixups, thanks.

BTW your mailer seems to have mangled your patch, so I had to apply it
manually. Please consider using git send-email for submitting patches in
the future.


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

Re: [Mesa3d-dev] Mesa (master): r300/compiler: Assert that array index is not negative.

[José F. <jfo...@vm...>]

On Fri, 2010-02-26 at 01:18 -0800, Corbin Simpson wrote:
> > Module: Mesa
> > Branch: master
> > Commit: e5c691f445e1c02e6e2f75b817b13d7024f7a3a6
> > URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=e5c691f445e1c02e6e2f75b817b13d7024f7a3a6
> >
> > Author: Vinson Lee <vlee at vmware.com>
> > Date:   Fri Feb 26 00:17:03 2010 -0800
> >
> > r300/compiler: Assert that array index is not negative.
> >
> > ---
> >
> > .../drivers/dri/r300/compiler/r500_fragprog_emit.c |    2 ++
> > 1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/r300/compiler/r500_fragprog_emit.c b/src/mesa/drivers/dri/r300/compiler/r500_fragprog_emit.c
> > index 829f028..710cae7 100644
> > --- a/src/mesa/drivers/dri/r300/compiler/r500_fragprog_emit.c
> > +++ b/src/mesa/drivers/dri/r300/compiler/r500_fragprog_emit.c
> > @@ -469,6 +469,8 @@ void r500BuildFragmentProgramHwCode(struct r300_fragment_program_compiler *compi
> > if (compiler->Base.Error)
> > return;
> >
> > + assert(code->inst_end >= 0);
> > +
> > if ((code->inst[code->inst_end].inst0 & R500_INST_TYPE_MASK) != R500_INST_TYPE_OUT) {
> > /* This may happen when dead-code elimination is disabled or
> > * when most of the fragment program logic is leading to a KIL */
> 
> Sorry, is this actually a problem? If this assertion is actually being
> hit, it sure would be nice to hear about it since it. Empty shaders
> shouldn't just be handled with debugging code.

Vinson has been cleaning up code base based on the results of coverity
static code analysis. 

Coverity generates thousands of errors/warnings for Mesa source code.
Not all errors/warnings reported by coverity are actually hit in
practice, but putting asserts and/or error handling code will at least
inform coverity that that can't ever happen, and allow the real errors
to stand out.

I imagine this is the case here.

Jose

Re: [Mesa3d-dev] Mesa (master): r300/compiler: Assert that array index is not negative.

[Corbin S. <mos...@gm...>]

> Module: Mesa
> Branch: master
> Commit: e5c691f445e1c02e6e2f75b817b13d7024f7a3a6
> URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=e5c691f445e1c02e6e2f75b817b13d7024f7a3a6
>
> Author: Vinson Lee <vlee at vmware.com>
> Date:   Fri Feb 26 00:17:03 2010 -0800
>
> r300/compiler: Assert that array index is not negative.
>
> ---
>
> .../drivers/dri/r300/compiler/r500_fragprog_emit.c |    2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/r300/compiler/r500_fragprog_emit.c b/src/mesa/drivers/dri/r300/compiler/r500_fragprog_emit.c
> index 829f028..710cae7 100644
> --- a/src/mesa/drivers/dri/r300/compiler/r500_fragprog_emit.c
> +++ b/src/mesa/drivers/dri/r300/compiler/r500_fragprog_emit.c
> @@ -469,6 +469,8 @@ void r500BuildFragmentProgramHwCode(struct r300_fragment_program_compiler *compi
> if (compiler->Base.Error)
> return;
>
> + assert(code->inst_end >= 0);
> +
> if ((code->inst[code->inst_end].inst0 & R500_INST_TYPE_MASK) != R500_INST_TYPE_OUT) {
> /* This may happen when dead-code elimination is disabled or
> * when most of the fragment program logic is leading to a KIL */

Sorry, is this actually a problem? If this assertion is actually being
hit, it sure would be nice to hear about it since it. Empty shaders
shouldn't just be handled with debugging code.

--
Only fools are easily impressed by what is only
barely beyond their reach. ~ Unknown

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

[Mesa3d-dev] Patch for eglplatform.h

[Tom C. <tom...@go...>]

With the attached patch applied, I can build Qt against Mesa's EGL &
GLES2 libraries as they currently stand in master. What's more,
examples/opengl/hellogl_es2 runs perfectly against the gallium swrast
driver. The i965 driver was less successful however (my X server
died). :-/

Dunno if people will agree with the patch, but I'd imagine it's not
just Qt which will have problems with egl including X11 headers?


Cheers,

Tom

[Mesa3d-dev] [PATCH] fix test progs from gl_API move

[Wil R. <wil...@gm...>]

Looks like these got missed.


diff --git a/progs/tests/Makefile b/progs/tests/Makefile
index 6c78abc..67efc3b 100644
--- a/progs/tests/Makefile
+++ b/progs/tests/Makefile
@@ -158,7 +158,7 @@ clean:
 # auto code generation
 getprocaddress: getprocaddress.c getproclist.h

-getproclist.h: $(TOP)/src/mesa/glapi/gl_API.xml getprocaddress.c
getprocaddress.py
+getproclist.h: $(TOP)/src/mesa/glapi/gen/gl_API.xml getprocaddress.c
getprocaddress.py
    python getprocaddress.py > getproclist.h

 arraytexture: arraytexture.o readtex.o
diff --git a/progs/tests/getprocaddress.py b/progs/tests/getprocaddress.py
index 699195b..e88ad4c 100644
--- a/progs/tests/getprocaddress.py
+++ b/progs/tests/getprocaddress.py
@@ -74,7 +74,7 @@ static struct name_test_pair functions[] = {"""


 if __name__ == '__main__':
-   file_name = "../../src/mesa/glapi/gl_API.xml"
+   file_name = "../../src/mesa/glapi/gen/gl_API.xml"

    try:
        (args, trail) = getopt.getopt(sys.argv[1:], "f:")

[Mesa3d-dev] [RFC] gallium-winsys-handle branch merge

[Jakob B. <ja...@vm...>]

Howdy

I'm hoping to merge the gallium-winsys-handle branch to master this weekend or early next week. The branch adds two new pipe screen functions to be used by the co state tracker (state tracker manger in new st_api.h speak). The branch also adds a new PIPE_TEXTURE_USAGE_SHARABLE flag telling the driver that the driver that the texture might be used for sharing. Even more so it also renames PIPE_TEXTURE_USAGE_PRIMARY to PIPE_TEXTURE_USAGE_SCANOUT just to make things clear. I also ported the egl,xorg,dri state trackers to the new interface and removing unneeded functions from drm_api making it even smaller, however I only ported i915g, i965 and svga to the new API. Looking at the commits where I port the other drivers it should be pretty clear what to do.

If people want I can merge master to this branch or create a rebased branch, I know nv has done some drm interface changes between the branch point and current master.

Cheers Jakob.

Re: [Mesa3d-dev] [PATCH] st/dri: don't enable EXT_draw_buffers2 by default

[Marek O. <ma...@gm...>]

On Tue, Feb 23, 2010 at 2:49 AM, Marek Olšák <ma...@gm...> wrote:

> On Mon, Feb 22, 2010 at 4:23 PM, Brian Paul <bri...@gm...>wrote:
>
>> On Sun, Feb 21, 2010 at 8:00 AM, Marek Olšák <ma...@gm...> wrote:
>> > Hi,
>> >
>> > the attached patch modifies st/dri to not enable EXT_draw_buffers2 by
>> > default because r300g and most probably even some other drivers can't
>> > support this extension. The drivers reporting support of
>> > PIPE_CAP_INDEP_BLEND_ENABLE are not affected by this patch.
>> >
>> > Please review.
>>
>> Hmm, I believe the extensions listed in dri_extensions.c are those
>> that _may_ be supported by drivers.  But its the st_extensions.c code
>> that queries the driver for various caps (such as
>> PIPE_CAP_INDEP_BLEND_ENABLE) and then turns on the extension if
>> applicable.
>>
>
> I stand corrected.
>
>
I was actually right the first time. The list in dri_extensions.c is being
advertised *regardless* of what a driver reports (tested and debugged). None
of the extensions on the list can be disabled using pipe_screen::get_param,
making the majority of feature caps useless. However, I can enable/disable
any extension which is *not* on the list using appropriate caps (if they
exist).

-Marek

Re: [Mesa3d-dev] Mesa removals

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

Kristian Høgsberg wrote:
> On Mon, Feb 22, 2010 at 11:38 AM, Brian Paul <br...@vm...> 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?
> 
> This was posted four days ago and I didn't hear any objections, only
> some nostalgia background noise.  I've removed all the drivers and
> subdirectories mentioned above and posted the result in the
> mesa-cleanup branch in
> 
>   git://anongit.freedesktop.org/~krh/mesa
> 
> Brian, if that looks ok to you, I can push that to the main mesa repo now

It looks like progs/windml/ wasn't completely removed.

Looks good otherwise.  Thanks.

-Brian

Re: [Mesa3d-dev] Remove color index rendering?

[Kristian H. <kr...@bi...>]

On Fri, Feb 19, 2010 at 10:43 PM, Corbin Simpson
<mos...@gm...> wrote:
> Can we doc it and comment it out? IME somebody will pop out and claim a use
> for it.

With git, which lets you search and query history fast and easily,
there's never really and excuse for commenting/#ifdef'ing something
out.  If somebody wants to revive CI rendering, digging it out from
git is going to be the least of his problems.

Kristian

> Posting from a mobile, pardon my terseness. ~ C.
>
> On Feb 19, 2010 5:19 PM, "Ian Romanick" <id...@fr...> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> While we're on the topic of removing dead weight, can we remove support
> for color index rendering?  None of the hardware drivers support color
> index rendering, and color index rendering is deprecated in OpenGL 3.0
> (and removed in 3.1).
>
> Can it please die in a fire?
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkt/Kd8ACgkQX1gOwKyEAw+zpQCgj+Yr0Bo3e6O3BijR5KYEds48
> DfIAniZibZEaXZsO0qYa9OW5745LM9xL
> =tcrK
> -----END PGP SIGNATURE-----
>
> ------------------------------------------------------------------------------
> Download Intel&#174; 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
>
> ------------------------------------------------------------------------------
> Download Intel&#174; 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] Mesa removals

[Kristian H. <kr...@bi...>]

On Mon, Feb 22, 2010 at 11:38 AM, Brian Paul <br...@vm...> 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?

This was posted four days ago and I didn't hear any objections, only
some nostalgia background noise.  I've removed all the drivers and
subdirectories mentioned above and posted the result in the
mesa-cleanup branch in

  git://anongit.freedesktop.org/~krh/mesa

Brian, if that looks ok to you, I can push that to the main mesa repo now

Kristian

Re: [Mesa3d-dev] makedepend in Mesa

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

On Thu, Feb 25, 2010 at 11:18 AM, Xavier Chantry
<cha...@gm...> wrote:
> On Tue, Feb 23, 2010 at 11:14 PM, Dan Nicholson <dbn...@gm...> wrote:
>>
>> We could use gcc directly for depends (I have a patch to do it), but:
>>
>> 1. I don't think it would actually help much in terms of rebuilds
>> since makedepend seems to do a perfectly adequate job of finding the
>> needed headers.
>>
>> 2. gcc expects to output a single make target for a single source
>> file. mesa just tosses all the source files at makedepend which
>> generates a depend file with a bunch of targets. gcc is phenomenally
>> slow doing the same. Changing the build to include one dep file per
>> source file would be a ton of churn.
>>
>> 3. The fast way automake does gcc dep tracking is to do it as a step
>> during the compile. Since gcc fully preprocesses the source file
>> before generating the make target, you can get it for free during the
>> compile. Doing as a separate step like mesa means you're throwing away
>> the preprocessing and then doing it again immediately afterward. The
>> time adds up.
>>
>> I guess what I'm saying is that I wouldn't bother with gcc dep
>> tracking unless it's coming as part of automake.
>>
>
> Thanks for all these explanations !
>
>>
>> configure checks for makedepend, but doesn't error if it's not found.
>> It probably should. Likewise, the commands running makedepend should
>> probably not be silenced with stderr redirected to /dev/null. That
>> would break builds for people using the static configs without
>> makedepend.
>>
>
> Why do we need static configs ?
> If I understand correctly, we have the choice between 1 autoconf file,
> and more than 100 static config files ?
> And autoconf can potentially capture all these static configurations and more ?

Because a lot of the vmware guys use the static configs. They like
being able to just do "make linux".

>> I think the problem is more that it's not used consistently since it
>> has to be setup manually in the Makefile vs. automatically like
>> automake.
>>
>
> My understanding of autotools is still very limited. mesa currently
> doesn't use automake, does it ?
> A git grep automake lets me believe that it was dropped in 5.1

Yeah, we just use autoconf to generate configs/autoconf. After that
it's treated just like one of the static configs. All the Makefiles
are manual.

> So currently makedepend needs to be setup manually in all the Makefiles ?
>
> And using automake would give a big advantage on the two sides :
> 1) automatic makedepend setup
> 2) efficient use of gcc dep tracking
> ?

Right, except automake doesn't use makedepend. It does the equivalent
with gcc's generation of make dependency rules. Look for the -M option
in gcc(1). Using automake and libtool would have a lot of advantages
over mesa's homegrown system. The big drawback is the added complexity
and the fact that Brian has historically wanted nothing to do with it.

>> I'd be comfortable having makedepend be a hard requirement in
>> configure. Otherwise, I'd rather have this be AC_MSG_WARN([your
>> message]) right after the AC_PATH_PROG for makedepend.
>>
>
> Actually I wanted to propose a hard requirement but then thought some
> people might complain.
> If I just put a AC_MSG_WARN right after AC_PATH_PROG, I am afraid it
> won't make a big difference as it won't be very visible.
> To make a hard requirement, I could just use AC_MSG_ERROR instead ?
>
> [I wonder if it wouldn't be easier to make scons work like I want to
> avoid all these problems.
> I believe I would just need to add nouveau support, and probably look
> into this :
> # TODO: Build several variants at the same time?
> # http://www.scons.org/wiki/SimultaneousVariantBuilds]

Well, that's for scons, which is completely independent of
autoconf/configs/Makefile. I believe the vmware guys use scons
primarily for building on windows, which the configs system can't
handle.

> diff --git a/configure.ac b/configure.ac
> index 485836a..a582337 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -28,8 +28,11 @@ AC_PROG_CPP
>  AC_PROG_CC
>  AC_PROG_CXX
>  AC_CHECK_PROGS([MAKE], [gmake make])
> -AC_PATH_PROG([MKDEP], [makedepend])
>  AC_PATH_PROG([SED], [sed])
> +AC_PATH_PROG([MKDEP], [makedepend], no)
> +if test "x$MKDEP" = xno; then
> +    AC_MSG_ERROR([makedepend not found])
> +fi

Yep, that would do it. In fact, when I wrote configure.ac originally,
I wanted it to be a hard requirement and assumed that AC_PATH_PROG
would error by default if it didn't find the program.

--
Dan

Re: [Mesa3d-dev] softpipe/llvmpipe SConscript

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

On Thu, Feb 25, 2010 at 6:12 PM, José Fonseca <jfo...@vm...> wrote:
>
> Thanks. Commited, with just a change: I still allow drivers=trace to
> avoid breaking all build infrastructure that's already using that
> option. I'll eventually remove the option once I've updated everywhere
> not to use it.
>

I did wonder about keeping backward compatibility, so that sounds
perfectly sane to me !

Re: [Mesa3d-dev] makedepend in Mesa

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

On Tue, Feb 23, 2010 at 11:14 PM, Dan Nicholson <dbn...@gm...> wrote:
>
> We could use gcc directly for depends (I have a patch to do it), but:
>
> 1. I don't think it would actually help much in terms of rebuilds
> since makedepend seems to do a perfectly adequate job of finding the
> needed headers.
>
> 2. gcc expects to output a single make target for a single source
> file. mesa just tosses all the source files at makedepend which
> generates a depend file with a bunch of targets. gcc is phenomenally
> slow doing the same. Changing the build to include one dep file per
> source file would be a ton of churn.
>
> 3. The fast way automake does gcc dep tracking is to do it as a step
> during the compile. Since gcc fully preprocesses the source file
> before generating the make target, you can get it for free during the
> compile. Doing as a separate step like mesa means you're throwing away
> the preprocessing and then doing it again immediately afterward. The
> time adds up.
>
> I guess what I'm saying is that I wouldn't bother with gcc dep
> tracking unless it's coming as part of automake.
>

Thanks for all these explanations !

>
> configure checks for makedepend, but doesn't error if it's not found.
> It probably should. Likewise, the commands running makedepend should
> probably not be silenced with stderr redirected to /dev/null. That
> would break builds for people using the static configs without
> makedepend.
>

Why do we need static configs ?
If I understand correctly, we have the choice between 1 autoconf file,
and more than 100 static config files ?
And autoconf can potentially capture all these static configurations and more ?

>
> I think the problem is more that it's not used consistently since it
> has to be setup manually in the Makefile vs. automatically like
> automake.
>

My understanding of autotools is still very limited. mesa currently
doesn't use automake, does it ?
A git grep automake lets me believe that it was dropped in 5.1

So currently makedepend needs to be setup manually in all the Makefiles ?

And using automake would give a big advantage on the two sides :
1) automatic makedepend setup
2) efficient use of gcc dep tracking
?

>
> I'd be comfortable having makedepend be a hard requirement in
> configure. Otherwise, I'd rather have this be AC_MSG_WARN([your
> message]) right after the AC_PATH_PROG for makedepend.
>

Actually I wanted to propose a hard requirement but then thought some
people might complain.
If I just put a AC_MSG_WARN right after AC_PATH_PROG, I am afraid it
won't make a big difference as it won't be very visible.
To make a hard requirement, I could just use AC_MSG_ERROR instead ?

[I wonder if it wouldn't be easier to make scons work like I want to
avoid all these problems.
I believe I would just need to add nouveau support, and probably look
into this :
# TODO: Build several variants at the same time?
# http://www.scons.org/wiki/SimultaneousVariantBuilds]

diff --git a/configure.ac b/configure.ac
index 485836a..a582337 100644
--- a/configure.ac
+++ b/configure.ac
@@ -28,8 +28,11 @@ AC_PROG_CPP
 AC_PROG_CC
 AC_PROG_CXX
 AC_CHECK_PROGS([MAKE], [gmake make])
-AC_PATH_PROG([MKDEP], [makedepend])
 AC_PATH_PROG([SED], [sed])
+AC_PATH_PROG([MKDEP], [makedepend], no)
+if test "x$MKDEP" = xno; then
+    AC_MSG_ERROR([makedepend not found])
+fi

 dnl Our fallback install-sh is a symlink to minstall. Use the existing
 dnl configuration in that case.

Re: [Mesa3d-dev] move normalized texel coordinates bit to sampler view

[michal <mi...@vm...>]

Christoph Bumiller wrote on 2010-02-25 19:39:
> On 25.02.2010 19:00, Brian Paul wrote:
>   
>> Roland Scheidegger wrote:
>>   
>>     
>>> On 25.02.2010 18:39, michal wrote:
>>>     
>>>       
>>>> Roland Scheidegger wrote on 2010-02-24 15:18:
>>>>       
>>>>         
>>>>> On 24.02.2010 12:48, Christoph Bumiller wrote:
>>>>>   
>>>>>         
>>>>>           
>>>>>> This wasn't a problem before because textures and samplers were
>>>>>> linked 1:1, but in view of the gallium-gpu4-texture-opcodes branch,
>>>>>> this coordinate normalization bit becomes a problem.
>>>>>>
>>>>>> NV50 hardware has that bit in the RESOURCE binding, and not the
>>>>>> SAMPLER binding, and you can imagine that this will lead to us having
>>>>>> to jump through a few annoying looking hoops to accomodate.
>>>>>>
>>>>>> As far as I can see, neither D3D10 nor D3D11 nor OpenGL nor CUDA have
>>>>>> sampler states that are decoupled from the texture, and which contain
>>>>>> a normalized coordinates bit, so it's worth considering not having it there
>>>>>> in gallium either.
>>>>>>
>>>>>> For OpenGL, unnormalized coordinates are only used for RECT textures,
>>>>>> and in this case it makes sense to make it a property of the texture.
>>>>>>     
>>>>>>           
>>>>>>             
>>>>> I agree this is not sampler state, but I don't quite agree this should
>>>>> be texture state.
>>>>> This changes how texture coordinates get interpreted in the interpolator
>>>>> - in that sense it is similar to the cylindrical texture coord wrap
>>>>> which we moved away from sampler state recently. This one got moved to
>>>>> shader declaration. I wonder if the normalization bit should be treated
>>>>> the same.
>>>>> Though OTOH you're quite right that in OpenGL this really is texture
>>>>> property (it is a different texture target after all), and afaik d3d
>>>>> doesn't support non-normalized coords (?). Hmm...
>>>>>
>>>>>   
>>>>>         
>>>>>           
>>>> Isn't it the case that for RECT targets we clear the bit, and for others 
>>>> we always set it?
>>>>
>>>> In mesa st I see:
>>>>
>>>>          if (texobj->Target != GL_TEXTURE_RECTANGLE_ARB)
>>>>             sampler->normalized_coords = 1;
>>>>
>>>> By definition, RECT texture with normalised coordinates is just an NPOT. 
>>>> If we removed this apparently redundant flag, would that make nouveau 
>>>> developers life easier?
>>>>       
>>>>         
>>> But we don't have rect targets in gallium hence we need the flag. I
>>> think conceptually this makes sense since for texture layouts etc.
>>> drivers won't care one bit if this is 2d npot or rect texture.
>>> Though I guess introducing rect targets instead would be another option.
>>>     
>>>       
>> We should also be thinking about texture array targets.  With a 2D 
>> texture array, the S and T coords would be normalized, but not R.
>>
>> I think we either need new texture targets for RECT, 1D_ARRAY, 
>> 2D_ARRAY, etc. or per-dimension normalization flags.  I'm thinking the 
>> former may be better (simpler) since textures are created as a 
>> particular type and not changed afterward.  We also know the texture 
>> type/target when we execute TEX shader instructions.  If it's part of 
>> sampler state it gives the impression that it's variable state, but it 
>> really isn't.
>>
>>   
>>     
> We'd also need a BUFFER target then, they also have scaled
> coordinates.
> The problem is I think that this drivers gallium a little towards
> catering towards specific APIs (OpenGL).
>
> OpenCL for instance does have a per sampler normalization bit
> iirc, but it seems there's no hardware that reflects this property.
>
> Then again, TGSI does have a RECT target already, so we might
> as well add corresponding PIPE targets.
>
> I want to remind again that the normalization bit only becomes
> problematic once samplers and textures can be independently
> combined, and that it seems older hardware can't nicely do this
> anyway, except if they take it upon them to recompile their shaders
> (although I hear some need to do that already ...)
>
> I admit I'm actually being a bit selfish here, trying to get the interface
> more adapted to nv50, but, if other hardware doesn't have conflicting
> views, why not ? Maybe I should accept nv50 is getting old.
>   
Why do you say that? NV50 is a DX10-level card -- it deserves better 
treatment. Your request is valid and we should go and ask gallium 
gatekeepers to get this change pushed.

Thanks.

Re: [Mesa3d-dev] move normalized texel coordinates bit to sampler view

[Christoph B. <e04...@st...>]

On 25.02.2010 19:00, Brian Paul wrote:
> Roland Scheidegger wrote:
>   
>> On 25.02.2010 18:39, michal wrote:
>>     
>>> Roland Scheidegger wrote on 2010-02-24 15:18:
>>>       
>>>> On 24.02.2010 12:48, Christoph Bumiller wrote:
>>>>   
>>>>         
>>>>> This wasn't a problem before because textures and samplers were
>>>>> linked 1:1, but in view of the gallium-gpu4-texture-opcodes branch,
>>>>> this coordinate normalization bit becomes a problem.
>>>>>
>>>>> NV50 hardware has that bit in the RESOURCE binding, and not the
>>>>> SAMPLER binding, and you can imagine that this will lead to us having
>>>>> to jump through a few annoying looking hoops to accomodate.
>>>>>
>>>>> As far as I can see, neither D3D10 nor D3D11 nor OpenGL nor CUDA have
>>>>> sampler states that are decoupled from the texture, and which contain
>>>>> a normalized coordinates bit, so it's worth considering not having it there
>>>>> in gallium either.
>>>>>
>>>>> For OpenGL, unnormalized coordinates are only used for RECT textures,
>>>>> and in this case it makes sense to make it a property of the texture.
>>>>>     
>>>>>           
>>>> I agree this is not sampler state, but I don't quite agree this should
>>>> be texture state.
>>>> This changes how texture coordinates get interpreted in the interpolator
>>>> - in that sense it is similar to the cylindrical texture coord wrap
>>>> which we moved away from sampler state recently. This one got moved to
>>>> shader declaration. I wonder if the normalization bit should be treated
>>>> the same.
>>>> Though OTOH you're quite right that in OpenGL this really is texture
>>>> property (it is a different texture target after all), and afaik d3d
>>>> doesn't support non-normalized coords (?). Hmm...
>>>>
>>>>   
>>>>         
>>> Isn't it the case that for RECT targets we clear the bit, and for others 
>>> we always set it?
>>>
>>> In mesa st I see:
>>>
>>>          if (texobj->Target != GL_TEXTURE_RECTANGLE_ARB)
>>>             sampler->normalized_coords = 1;
>>>
>>> By definition, RECT texture with normalised coordinates is just an NPOT. 
>>> If we removed this apparently redundant flag, would that make nouveau 
>>> developers life easier?
>>>       
>> But we don't have rect targets in gallium hence we need the flag. I
>> think conceptually this makes sense since for texture layouts etc.
>> drivers won't care one bit if this is 2d npot or rect texture.
>> Though I guess introducing rect targets instead would be another option.
>>     
> We should also be thinking about texture array targets.  With a 2D 
> texture array, the S and T coords would be normalized, but not R.
>
> I think we either need new texture targets for RECT, 1D_ARRAY, 
> 2D_ARRAY, etc. or per-dimension normalization flags.  I'm thinking the 
> former may be better (simpler) since textures are created as a 
> particular type and not changed afterward.  We also know the texture 
> type/target when we execute TEX shader instructions.  If it's part of 
> sampler state it gives the impression that it's variable state, but it 
> really isn't.
>
>   
We'd also need a BUFFER target then, they also have scaled
coordinates.
The problem is I think that this drivers gallium a little towards
catering towards specific APIs (OpenGL).

OpenCL for instance does have a per sampler normalization bit
iirc, but it seems there's no hardware that reflects this property.

Then again, TGSI does have a RECT target already, so we might
as well add corresponding PIPE targets.

I want to remind again that the normalization bit only becomes
problematic once samplers and textures can be independently
combined, and that it seems older hardware can't nicely do this
anyway, except if they take it upon them to recompile their shaders
(although I hear some need to do that already ...)

I admit I'm actually being a bit selfish here, trying to get the interface
more adapted to nv50, but, if other hardware doesn't have conflicting
views, why not ? Maybe I should accept nv50 is getting old.

What about future hardware ? Well, we don't know how Fermi works
in this respect yet, and I don't think $MANUFACTURER will tell us ..

Christoph
> -Brian
>
>
> ------------------------------------------------------------------------------
> 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] move normalized texel coordinates bit to sampler view

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

On Thu, Feb 25, 2010 at 11:00:28AM -0700, Brian Paul wrote:
> We should also be thinking about texture array targets.  With a 2D 
> texture array, the S and T coords would be normalized, but not R.
> 
> I think we either need new texture targets for RECT, 1D_ARRAY, 
> 2D_ARRAY, etc. or per-dimension normalization flags.  I'm thinking the 
> former may be better (simpler) since textures are created as a 
> particular type and not changed afterward.  We also know the texture 
> type/target when we execute TEX shader instructions.  If it's part of 
> sampler state it gives the impression that it's variable state, but it 
> really isn't.

The latter is probably unworkable because :
- filtering is done only on the selected texture and not between
  elements of the array
- mipmaps are per-selected texture, giving a very different layout
  than the dim+1 texture type

Intel has different hardware types for say 2D_ARRAY vs. 3D, probably
for these reasons.

  OG.

Re: [Mesa3d-dev] move normalized texel coordinates bit to sampler view

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

Roland Scheidegger wrote:
> On 25.02.2010 18:39, michal wrote:
>> Roland Scheidegger wrote on 2010-02-24 15:18:
>>> On 24.02.2010 12:48, Christoph Bumiller wrote:
>>>   
>>>> This wasn't a problem before because textures and samplers were
>>>> linked 1:1, but in view of the gallium-gpu4-texture-opcodes branch,
>>>> this coordinate normalization bit becomes a problem.
>>>>
>>>> NV50 hardware has that bit in the RESOURCE binding, and not the
>>>> SAMPLER binding, and you can imagine that this will lead to us having
>>>> to jump through a few annoying looking hoops to accomodate.
>>>>
>>>> As far as I can see, neither D3D10 nor D3D11 nor OpenGL nor CUDA have
>>>> sampler states that are decoupled from the texture, and which contain
>>>> a normalized coordinates bit, so it's worth considering not having it there
>>>> in gallium either.
>>>>
>>>> For OpenGL, unnormalized coordinates are only used for RECT textures,
>>>> and in this case it makes sense to make it a property of the texture.
>>>>     
>>> I agree this is not sampler state, but I don't quite agree this should
>>> be texture state.
>>> This changes how texture coordinates get interpreted in the interpolator
>>> - in that sense it is similar to the cylindrical texture coord wrap
>>> which we moved away from sampler state recently. This one got moved to
>>> shader declaration. I wonder if the normalization bit should be treated
>>> the same.
>>> Though OTOH you're quite right that in OpenGL this really is texture
>>> property (it is a different texture target after all), and afaik d3d
>>> doesn't support non-normalized coords (?). Hmm...
>>>
>>>   
>> Isn't it the case that for RECT targets we clear the bit, and for others 
>> we always set it?
>>
>> In mesa st I see:
>>
>>          if (texobj->Target != GL_TEXTURE_RECTANGLE_ARB)
>>             sampler->normalized_coords = 1;
>>
>> By definition, RECT texture with normalised coordinates is just an NPOT. 
>> If we removed this apparently redundant flag, would that make nouveau 
>> developers life easier?
> But we don't have rect targets in gallium hence we need the flag. I
> think conceptually this makes sense since for texture layouts etc.
> drivers won't care one bit if this is 2d npot or rect texture.
> Though I guess introducing rect targets instead would be another option.

We should also be thinking about texture array targets.  With a 2D 
texture array, the S and T coords would be normalized, but not R.

I think we either need new texture targets for RECT, 1D_ARRAY, 
2D_ARRAY, etc. or per-dimension normalization flags.  I'm thinking the 
former may be better (simpler) since textures are created as a 
particular type and not changed afterward.  We also know the texture 
type/target when we execute TEX shader instructions.  If it's part of 
sampler state it gives the impression that it's variable state, but it 
really isn't.

-Brian

Re: [Mesa3d-dev] move normalized texel coordinates bit to sampler view

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

On 25.02.2010 18:39, michal wrote:
> Roland Scheidegger wrote on 2010-02-24 15:18:
>> On 24.02.2010 12:48, Christoph Bumiller wrote:
>>   
>>> This wasn't a problem before because textures and samplers were
>>> linked 1:1, but in view of the gallium-gpu4-texture-opcodes branch,
>>> this coordinate normalization bit becomes a problem.
>>>
>>> NV50 hardware has that bit in the RESOURCE binding, and not the
>>> SAMPLER binding, and you can imagine that this will lead to us having
>>> to jump through a few annoying looking hoops to accomodate.
>>>
>>> As far as I can see, neither D3D10 nor D3D11 nor OpenGL nor CUDA have
>>> sampler states that are decoupled from the texture, and which contain
>>> a normalized coordinates bit, so it's worth considering not having it there
>>> in gallium either.
>>>
>>> For OpenGL, unnormalized coordinates are only used for RECT textures,
>>> and in this case it makes sense to make it a property of the texture.
>>>     
>> I agree this is not sampler state, but I don't quite agree this should
>> be texture state.
>> This changes how texture coordinates get interpreted in the interpolator
>> - in that sense it is similar to the cylindrical texture coord wrap
>> which we moved away from sampler state recently. This one got moved to
>> shader declaration. I wonder if the normalization bit should be treated
>> the same.
>> Though OTOH you're quite right that in OpenGL this really is texture
>> property (it is a different texture target after all), and afaik d3d
>> doesn't support non-normalized coords (?). Hmm...
>>
>>   
> Isn't it the case that for RECT targets we clear the bit, and for others 
> we always set it?
> 
> In mesa st I see:
> 
>          if (texobj->Target != GL_TEXTURE_RECTANGLE_ARB)
>             sampler->normalized_coords = 1;
> 
> By definition, RECT texture with normalised coordinates is just an NPOT. 
> If we removed this apparently redundant flag, would that make nouveau 
> developers life easier?
But we don't have rect targets in gallium hence we need the flag. I
think conceptually this makes sense since for texture layouts etc.
drivers won't care one bit if this is 2d npot or rect texture.
Though I guess introducing rect targets instead would be another option.

Roland


> 
>>   
>>> And, finally, I've seen you reverted the changes for independent image
>>> and sampler index in the texture opcodes. What's up with that ?
>>> Is the code not nice enough, or has the idea been discarded and by problem
>>> disappears ?
>>>
>>>     
> 
> Please consider this branch dead. It will be easier for me to introduce 
> new, optional sampler and fetch opcodes a'la GL 3.0. There's just too 
> much code to fix and test and we still want the older hardware not to 
> stand on its head to try and translate back to old model.
> 
> Thanks.

Re: [Mesa3d-dev] move normalized texel coordinates bit to sampler view

[Alex D. <ale...@gm...>]

On Thu, Feb 25, 2010 at 12:39 PM, michal <mi...@vm...> wrote:
> Roland Scheidegger wrote on 2010-02-24 15:18:
>> On 24.02.2010 12:48, Christoph Bumiller wrote:
>>
>>> This wasn't a problem before because textures and samplers were
>>> linked 1:1, but in view of the gallium-gpu4-texture-opcodes branch,
>>> this coordinate normalization bit becomes a problem.
>>>
>>> NV50 hardware has that bit in the RESOURCE binding, and not the
>>> SAMPLER binding, and you can imagine that this will lead to us having
>>> to jump through a few annoying looking hoops to accomodate.
>>>
>>> As far as I can see, neither D3D10 nor D3D11 nor OpenGL nor CUDA have
>>> sampler states that are decoupled from the texture, and which contain
>>> a normalized coordinates bit, so it's worth considering not having it there
>>> in gallium either.
>>>
>>> For OpenGL, unnormalized coordinates are only used for RECT textures,
>>> and in this case it makes sense to make it a property of the texture.
>>>
>>
>> I agree this is not sampler state, but I don't quite agree this should
>> be texture state.
>> This changes how texture coordinates get interpreted in the interpolator
>> - in that sense it is similar to the cylindrical texture coord wrap
>> which we moved away from sampler state recently. This one got moved to
>> shader declaration. I wonder if the normalization bit should be treated
>> the same.
>> Though OTOH you're quite right that in OpenGL this really is texture
>> property (it is a different texture target after all), and afaik d3d
>> doesn't support non-normalized coords (?). Hmm...
>>
>>
> Isn't it the case that for RECT targets we clear the bit, and for others
> we always set it?
>
> In mesa st I see:
>
>         if (texobj->Target != GL_TEXTURE_RECTANGLE_ARB)
>            sampler->normalized_coords = 1;
>
> By definition, RECT texture with normalised coordinates is just an NPOT.
> If we removed this apparently redundant flag, would that make nouveau
> developers life easier?
>

FWIW, r3xx-r5xx always requires normalized coords, the normalization
is currently done in the shader.  On r6xx+, you can specify normalized
or non-normalized coords in the tex instructions.

Alex


>>
>>
>>> And, finally, I've seen you reverted the changes for independent image
>>> and sampler index in the texture opcodes. What's up with that ?
>>> Is the code not nice enough, or has the idea been discarded and by problem
>>> disappears ?
>>>
>>>
>
> Please consider this branch dead. It will be easier for me to introduce
> new, optional sampler and fetch opcodes a'la GL 3.0. There's just too
> much code to fix and test and we still want the older hardware not to
> stand on its head to try and translate back to old model.
>
> Thanks.
>
> ------------------------------------------------------------------------------
> Download Intel&#174; 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] move normalized texel coordinates bit to sampler view

[michal <mi...@vm...>]

Roland Scheidegger wrote on 2010-02-24 15:18:
> On 24.02.2010 12:48, Christoph Bumiller wrote:
>   
>> This wasn't a problem before because textures and samplers were
>> linked 1:1, but in view of the gallium-gpu4-texture-opcodes branch,
>> this coordinate normalization bit becomes a problem.
>>
>> NV50 hardware has that bit in the RESOURCE binding, and not the
>> SAMPLER binding, and you can imagine that this will lead to us having
>> to jump through a few annoying looking hoops to accomodate.
>>
>> As far as I can see, neither D3D10 nor D3D11 nor OpenGL nor CUDA have
>> sampler states that are decoupled from the texture, and which contain
>> a normalized coordinates bit, so it's worth considering not having it there
>> in gallium either.
>>
>> For OpenGL, unnormalized coordinates are only used for RECT textures,
>> and in this case it makes sense to make it a property of the texture.
>>     
>
> I agree this is not sampler state, but I don't quite agree this should
> be texture state.
> This changes how texture coordinates get interpreted in the interpolator
> - in that sense it is similar to the cylindrical texture coord wrap
> which we moved away from sampler state recently. This one got moved to
> shader declaration. I wonder if the normalization bit should be treated
> the same.
> Though OTOH you're quite right that in OpenGL this really is texture
> property (it is a different texture target after all), and afaik d3d
> doesn't support non-normalized coords (?). Hmm...
>
>   
Isn't it the case that for RECT targets we clear the bit, and for others 
we always set it?

In mesa st I see:

         if (texobj->Target != GL_TEXTURE_RECTANGLE_ARB)
            sampler->normalized_coords = 1;

By definition, RECT texture with normalised coordinates is just an NPOT. 
If we removed this apparently redundant flag, would that make nouveau 
developers life easier?

>
>   
>> And, finally, I've seen you reverted the changes for independent image
>> and sampler index in the texture opcodes. What's up with that ?
>> Is the code not nice enough, or has the idea been discarded and by problem
>> disappears ?
>>
>>     

Please consider this branch dead. It will be easier for me to introduce 
new, optional sampler and fetch opcodes a'la GL 3.0. There's just too 
much code to fix and test and we still want the older hardware not to 
stand on its head to try and translate back to old model.

Thanks.

Re: [Mesa3d-dev] softpipe/llvmpipe SConscript

[José F. <jfo...@vm...>]

On Tue, 2010-02-23 at 13:09 -0800, Xavier Chantry wrote:
> On Tue, Feb 23, 2010 at 10:18 AM, José Fonseca <jfo...@vm...> wrote:
> > But there is another thing that we can do: take out trace from the scons
> > options and always built it, as there are so many state trackers and
> > winsys that rely on it for debug building, and trace can really build
> > anywhere and is thin so there's no point is making it an option.
> >
> 
> I like this a lot, see attached patch.
> This is my first time editing scons files so I hope I got it right.
> 
> >> A side question :
> >> line 21 : if not set(('softpipe', 'llvmpipe',
> >> 'trace')).intersection(env['drivers']):
> >>     print 'warning: no supported pipe driver: skipping build of xlib libGL.so'
> >>     Return()
> >>
> >> But below in the script (line 41-58), the drivers used are softpipe ,
> >> llvmpipe and cell.
> >> Should trace be replaced by cell in the above check ?
> >
> > Yes, I think so.
> >
> 
> Also changed in attached patch.

Thanks. Commited, with just a change: I still allow drivers=trace to
avoid breaking all build infrastructure that's already using that
option. I'll eventually remove the option once I've updated everywhere
not to use it.

Jose

Re: [Mesa3d-dev] Patch to fix -m32 for progs/glsl

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

Török Edvin wrote:
> Hi,
> 
> I had to apply the following patch to build mesa as 32-bit,
> on a 64-bit Debian system (so that wine, and all else get proper
> 3D accelereration with the new r600 driver).
> 
> progs/glsl is built by default, but it was not using -m32.
> Please apply the patch to mesa git master, it is a one-line makefile fix.

Committed.  Thanks.

-Brian