mesa3d-dev

Re: [Mesa3d-dev] Mesa (7.8): apple: Don't build gallium

[Jeremy H. <jer...@fr...>]

Crap.  I accidentally pushed to mainline instead of my tree, sorry.  I pushed a commit to 7.8 that reverts that series of patches.

These changes aren't ready for mainline.  I want to clean them up a bit more first.  If you're interested in commenting now, I'd appreciate feedback, but right now the convergence of these two trains is still a little ways off.

On Apr 1, 2010, at 15:34, Vinson Lee wrote:

> Hi,
> 
> Is there any specific reason for removing Gallium from the Apple build?

It doesn't build due to some bad Makefile in gallium that I haven't had a chance to dig into yet:

make[4]: *** No rule to make target `-lm', needed by `../../../../lib/libOpenVG.so'.  Stop.

--Jeremy

[Mesa3d-dev] [Bug 27418] New: latest eglut patches break build

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

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

           Summary: latest eglut patches break build
           Product: Mesa
           Version: git
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Mesa core
        AssignedTo: mes...@li...
        ReportedBy: mar...@gm...


When I try to compile mesa I get the following error:
make[3]: Leaving directory
`/home/martin/abs/2_xorg/5_-_mesa-full/src/mesa-build/progs/egl/eglut'
gcc -march=native -mtune=native -O2 -g -Wall -Wmissing-prototypes -std=c99
-ffast-math -fvisibility=hidden -fno-strict-aliasing  -fPIC  -DUSE_X86_ASM
-DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS
-DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS -DPTHREADS
-DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
-DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XEXTPROTO_71 -Wl,--hash-style=gnu
-Wl,--as-needed -o eglgears_x11 eglgears.o -L../../../lib -lEGL -lGL -lm
-L../../../progs/egl/eglut -leglut-x11 -lX11
../../../progs/egl/eglut/libeglut-x11.a(eglut.o): In function
`_eglutDefaultKeyboard':
/home/martin/abs/2_xorg/5_-_mesa-full/src/mesa-build/progs/egl/eglut/eglut.c:256:
undefined reference to `eglMakeCurrent'
../../../progs/egl/eglut/libeglut-x11.a(eglut.o): In function
`_eglutDestroyWindow':
/home/martin/abs/2_xorg/5_-_mesa-full/src/mesa-build/progs/egl/eglut/eglut.c:56:
undefined reference to `eglDestroySurface'
/home/martin/abs/2_xorg/5_-_mesa-full/src/mesa-build/progs/egl/eglut/eglut.c:60:
undefined reference to `eglDestroyContext'
../../../progs/egl/eglut/libeglut-x11.a(eglut.o): In function `_eglutFini':
/home/martin/abs/2_xorg/5_-_mesa-full/src/mesa-build/progs/egl/eglut/eglut.c:246:
undefined reference to `eglTerminate'
../../../progs/egl/eglut/libeglut-x11.a(eglut.o): In function `eglutInit':
/home/martin/abs/2_xorg/5_-_mesa-full/src/mesa-build/progs/egl/eglut/eglut.c:190:
undefined reference to `eglGetDisplay'
/home/martin/abs/2_xorg/5_-_mesa-full/src/mesa-build/progs/egl/eglut/eglut.c:192:
undefined reference to `eglInitialize'
/home/martin/abs/2_xorg/5_-_mesa-full/src/mesa-build/progs/egl/eglut/eglut.c:197:
undefined reference to `eglQueryString'
../../../progs/egl/eglut/libeglut-x11.a(eglut.o): In function
`_eglutChooseConfig':
/home/martin/abs/2_xorg/5_-_mesa-full/src/mesa-build/progs/egl/eglut/eglut.c:95:
undefined reference to `eglChooseConfig'
../../../progs/egl/eglut/libeglut-x11.a(eglut.o): In function
`_eglutCreateWindow':
/home/martin/abs/2_xorg/5_-_mesa-full/src/mesa-build/progs/egl/eglut/eglut.c:134:
undefined reference to `eglBindAPI'
/home/martin/abs/2_xorg/5_-_mesa-full/src/mesa-build/progs/egl/eglut/eglut.c:135:
undefined reference to `eglCreateContext'
../../../progs/egl/eglut/libeglut-x11.a(eglut.o): In function
`eglutCreateWindow':
/home/martin/abs/2_xorg/5_-_mesa-full/src/mesa-build/progs/egl/eglut/eglut.c:278:
undefined reference to `eglMakeCurrent'
../../../progs/egl/eglut/libeglut-x11.a(eglut.o): In function
`_eglutCreateWindow':
/home/martin/abs/2_xorg/5_-_mesa-full/src/mesa-build/progs/egl/eglut/eglut.c:147:
undefined reference to `eglCreatePixmapSurface'
/home/martin/abs/2_xorg/5_-_mesa-full/src/mesa-build/progs/egl/eglut/eglut.c:143:
undefined reference to `eglCreateWindowSurface'
../../../progs/egl/eglut/libeglut-x11.a(eglut_x11.o): In function
`_eglutNativeEventLoop':
/home/martin/abs/2_xorg/5_-_mesa-full/src/mesa-build/progs/egl/eglut/eglut_x11.c:217:
undefined reference to `eglSwapBuffers'
../../../progs/egl/eglut/libeglut-x11.a(eglut_x11.o): In function
`_eglutNativeInitWindow':
/home/martin/abs/2_xorg/5_-_mesa-full/src/mesa-build/progs/egl/eglut/eglut_x11.c:34:
undefined reference to `eglGetConfigAttrib'


-- 
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] How do we init half float tables?

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

OK.

I'd like to add that u_atomic.h already requires either GCC, MSVC or
Solaris, and GCC and MSVC are already supported by this system.
Thus we do indeed now have a simple way to do global constructors,
that only removes support for non-GCC Solaris until someone figures
out how to do that.

And it's relatively simple, you just have to figure out the section
name of the global constructor table, and how to instruct the specific
compiler to put a variable in a specific section.

GCC even has __attribute__((constructor)) which does it all for you.

At any rate, util_format_s3tc_init has similar issues, and is
currently called from a few places.
I think the best thing to do to implement your suggestion is adding an
util_format_init that calls both init functions and leave the
UTIL_INIT code in place (since it seems we now got it right): it is
easy to remove by deleting u_init.h if desired.

Re: [Mesa3d-dev] How do we init half float tables?

[Brian P. <bri...@gm...>]

On Thu, Apr 1, 2010 at 4:29 PM, Luca Barbieri <lu...@lu...> wrote:
> The half float conversion code initially used a global C++ constructor
> to initialize the tables.
>
> That fails to work since ld does not get the symbol from the shared
> library, so I changed to use register a global constructor from C,
> using GCC-  or MSVC-specific code.
>
> This is not necessarily the best option, but clearly putting a check
> in the functions as Corbin did is a bad idea performance-wise.
>
> So, how should this be done?
>
> Options are:
> 1. Revert Corbin Simpsons's commit and if anyone complains about an
> unsupported compiler, implement UTIL_INIT for that compiler too
> 2a. Write the init module in C++ and use portable global constructor
> syntax (but with other C++-related problems)
> 2b. Write an auxiliary file in C++ with a global constructor and
> reference it from the C init file so the static linker pulls it from
> the .a
> 3. Have all modules that need half float conversion directly or
> indirectly call the init functions in their init code
> 4. Make the build pregenerate the tables and ship them in the executables
>
> Option 1:
> Pros: just works, other auxiliary modules can use the same system
> Cons: need to write UTIL_INIT for each compiler, only GCC and MSVC
> (and compatible ones) are currently supported
>
> Option 2a:
> Pros: no compiler-specific UTIL_INIT
> Cons: significant code written in C++ instead of C and you must link
> all targets with a C++ compiler or use compiler-specific options to
> prevent stuff like the G++ personality causing the link to fail
>
> Option 2b:
> Like option 2a, but
> Pro: less code written in C++
> Con: need an extra C++ file for every module with data to be initialized
>
> Option 3:
> Pros: none of the cons of the other options
> Cons: cumbersome to do, must not forget to call the init function or
> you get silent corruption. Init calls creep through the whole
> codebase.
>
> Option 4:
> Pros: no need to do anything at runtime, pages can be shared between OpenGL apps
> Cons: need to write a special table generator, all DRI drivers get
> 10KB larger, solution does not apply to all similar problems
>
> I would lean for either option 1 or option 4, perhaps option 4
> considering there seems to be disagreement over option 1.
> Option 4 however is likely not universally applicable (not everything
> can necessarily be pregenerated), so I'd keep the UTIL_INIT code
> anyway.
>
> Which one do we pick?

#3.  Yeah, in this day and age we should have a nice way to do global
constructors but we don't.  This solution is simple.  A debug-only
assert could be used to check that the table's initialized.  It's not
that big of deal.

-Brian

[Mesa3d-dev] How do we init half float tables?

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

The half float conversion code initially used a global C++ constructor
to initialize the tables.

That fails to work since ld does not get the symbol from the shared
library, so I changed to use register a global constructor from C,
using GCC-  or MSVC-specific code.

This is not necessarily the best option, but clearly putting a check
in the functions as Corbin did is a bad idea performance-wise.

So, how should this be done?

Options are:
1. Revert Corbin Simpsons's commit and if anyone complains about an
unsupported compiler, implement UTIL_INIT for that compiler too
2a. Write the init module in C++ and use portable global constructor
syntax (but with other C++-related problems)
2b. Write an auxiliary file in C++ with a global constructor and
reference it from the C init file so the static linker pulls it from
the .a
3. Have all modules that need half float conversion directly or
indirectly call the init functions in their init code
4. Make the build pregenerate the tables and ship them in the executables

Option 1:
Pros: just works, other auxiliary modules can use the same system
Cons: need to write UTIL_INIT for each compiler, only GCC and MSVC
(and compatible ones) are currently supported

Option 2a:
Pros: no compiler-specific UTIL_INIT
Cons: significant code written in C++ instead of C and you must link
all targets with a C++ compiler or use compiler-specific options to
prevent stuff like the G++ personality causing the link to fail

Option 2b:
Like option 2a, but
Pro: less code written in C++
Con: need an extra C++ file for every module with data to be initialized

Option 3:
Pros: none of the cons of the other options
Cons: cumbersome to do, must not forget to call the init function or
you get silent corruption. Init calls creep through the whole
codebase.

Option 4:
Pros: no need to do anything at runtime, pages can be shared between OpenGL apps
Cons: need to write a special table generator, all DRI drivers get
10KB larger, solution does not apply to all similar problems

I would lean for either option 1 or option 4, perhaps option 4
considering there seems to be disagreement over option 1.
Option 4 however is likely not universally applicable (not everything
can necessarily be pregenerated), so I'd keep the UTIL_INIT code
anyway.

Which one do we pick?

Re: [Mesa3d-dev] [PATCH 2/2] xdemos: Build object files first

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

On Thu, Apr 1, 2010 at 2:40 PM, Jeremy Huddleston
<jer...@fr...> wrote:
>
> On Apr 1, 2010, at 14:18, Dan Nicholson wrote:
>
>>> +$(PROGS): $(PROGS:%=%.o)
>>
>> Is this necessary? I would think the prereq would be picked up
>> implicitly like the .c from the .o.
>
> Nope.  Without this, it tries to compile the .c directly to the executable rather than the .o first.

Even after you remove the .SUFFIXES lines? Yeah, I guess it would have
that assumption since the names are the same.

>
>>> +yuvrect_client: yuvrect_client.o
>>> +       $(APP_CC) $< $(LDFLAGS) $(LIBS) -l$(GLU_LIB) -o $@
>>
>> You dropped the CFLAGS from this last one, which can break when people
>> put things like -m32 there.
>
> That should be in LDFLAGS as well.  If anything, this fixes a problem where someone might (I have no idea why) do:
>
> CFLAGS="-arch i386 -arch x86_64"
> LDFLAGS="-arch x86_64"
>
> In that case, we'd obviously want the final exec to be x86_64 only and the intermediate object files to be both i386 and x86_64.  The way things are currently, the exec would accidentally be 2-way-fat.

automake/libtool certainly passes both CFLAGS and LDFLAGS during the
linking step. All the other targets in this same Makefile do, too. For
better or worse, I think we need to pass the CFLAGS during the link.

--
Dan

Re: [Mesa3d-dev] [PATCH 1/2] xdemos: Fix a build failure for non-autoconf configs

[tom f. <tf...@al...>]

Jeremy Huddleston <jer...@fr...> writes:
> > BTW, what config are you using, and what prevents you from using
> > autoconf?
>
> I can't use autoconf because it is nowhere near capable of handling
> darwin, and I haven't wanted to address the issue until the
> transition to autotools was completed.

We're building swrast on Darwin using autoconf, and have been since
7.4.  I know of an issue with glu on OS X 10.4, but other than that
things were fine, last I checked (been a while, admittedly).

Could you please report bugs / ping this ML with your autoconf build
issues on Darwin?

-tom

Re: [Mesa3d-dev] [PATCH 1/2] xdemos: Fix a build failure for non-autoconf configs

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

On Thu, Apr 1, 2010 at 2:36 PM, Jeremy Huddleston
<jer...@fr...> wrote:
>
> On Apr 1, 2010, at 14:10, Dan Nicholson wrote:
>
>> On Thu, Apr 1, 2010 at 12:35 PM, Jeremy Huddleston
>> <jer...@fr...> wrote:
>>>
>>> Signed-off-by: Jeremy Huddleston <jer...@ap...>
>>> ---
>>>  progs/xdemos/Makefile |    2 +-
>>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/progs/xdemos/Makefile b/progs/xdemos/Makefile
>>> index e87d55d..d5c627a 100644
>>> --- a/progs/xdemos/Makefile
>>> +++ b/progs/xdemos/Makefile
>>> @@ -11,7 +11,7 @@ LIB_DEP = $(TOP)/$(LIB_DIR)/$(GL_LIB_NAME)
>>>  # Add X11 and pthread libs to satisfy GNU gold.
>>>  APP_LIB_DEPS += -lX11 -lpthread
>>>
>>> -LIBS = -L$(TOP)/$(LIB_DIR) -l$(GL_LIB) -L$(libdir) $(APP_LIB_DEPS)
>>> +LIBS = -L$(TOP)/$(LIB_DIR) -l$(GL_LIB) -L$(INSTALL_LIB_DIR) $(APP_LIB_DEPS)
>>
>> Is this against master? We changed this to use $(X11_LIBS), which is
>> unfortunately only filled in by configure. BTW, what config are you
>> using, and what prevents you from using autoconf?
>
> This is against 7.8 ... perhaps you should cherry-pick the appropriate change into the 7.8 branch then.

Well, now I'm getting conflicts because you pushed this patch 25
minutes after you posted it. I'll try to straighten it out, though.

> I'm using the "darwin" config.  I can't use autoconf because it is nowhere near capable of handling darwin, and I haven't wanted to address the issue until the transition to autotools was completed.

I don't know if there is more of a transition to complete.

--
Dan

Re: [Mesa3d-dev] [PATCH 2/2] xdemos: Build object files first

[Jeremy H. <jer...@fr...>]

On Apr 1, 2010, at 14:18, Dan Nicholson wrote:

>> +$(PROGS): $(PROGS:%=%.o)
> 
> Is this necessary? I would think the prereq would be picked up
> implicitly like the .c from the .o.

Nope.  Without this, it tries to compile the .c directly to the executable rather than the .o first.

>> +yuvrect_client: yuvrect_client.o
>> +       $(APP_CC) $< $(LDFLAGS) $(LIBS) -l$(GLU_LIB) -o $@
> 
> You dropped the CFLAGS from this last one, which can break when people
> put things like -m32 there.

That should be in LDFLAGS as well.  If anything, this fixes a problem where someone might (I have no idea why) do:

CFLAGS="-arch i386 -arch x86_64"
LDFLAGS="-arch x86_64"

In that case, we'd obviously want the final exec to be x86_64 only and the intermediate object files to be both i386 and x86_64.  The way things are currently, the exec would accidentally be 2-way-fat.

--Jeremy

Re: [Mesa3d-dev] [PATCH 1/2] xdemos: Fix a build failure for non-autoconf configs

[Jeremy H. <jer...@fr...>]

On Apr 1, 2010, at 14:10, Dan Nicholson wrote:

> On Thu, Apr 1, 2010 at 12:35 PM, Jeremy Huddleston
> <jer...@fr...> wrote:
>> 
>> Signed-off-by: Jeremy Huddleston <jer...@ap...>
>> ---
>>  progs/xdemos/Makefile |    2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>> 
>> diff --git a/progs/xdemos/Makefile b/progs/xdemos/Makefile
>> index e87d55d..d5c627a 100644
>> --- a/progs/xdemos/Makefile
>> +++ b/progs/xdemos/Makefile
>> @@ -11,7 +11,7 @@ LIB_DEP = $(TOP)/$(LIB_DIR)/$(GL_LIB_NAME)
>>  # Add X11 and pthread libs to satisfy GNU gold.
>>  APP_LIB_DEPS += -lX11 -lpthread
>> 
>> -LIBS = -L$(TOP)/$(LIB_DIR) -l$(GL_LIB) -L$(libdir) $(APP_LIB_DEPS)
>> +LIBS = -L$(TOP)/$(LIB_DIR) -l$(GL_LIB) -L$(INSTALL_LIB_DIR) $(APP_LIB_DEPS)
> 
> Is this against master? We changed this to use $(X11_LIBS), which is
> unfortunately only filled in by configure. BTW, what config are you
> using, and what prevents you from using autoconf?

This is against 7.8 ... perhaps you should cherry-pick the appropriate change into the 7.8 branch then.

I'm using the "darwin" config.  I can't use autoconf because it is nowhere near capable of handling darwin, and I haven't wanted to address the issue until the transition to autotools was completed.

Re: [Mesa3d-dev] [PATCH 2/2] xdemos: Build object files first

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

On Thu, Apr 1, 2010 at 12:36 PM, Jeremy Huddleston
<jer...@fr...> wrote:
>
> This helps debugging on darwin.
>
> Signed-off-by: Jeremy Huddleston <jer...@ap...>
> ---
>  progs/xdemos/Makefile |   45 +++++++++++++++------------------------------
>  1 files changed, 15 insertions(+), 30 deletions(-)
>
> diff --git a/progs/xdemos/Makefile b/progs/xdemos/Makefile
> index d5c627a..29cba0c 100644
> --- a/progs/xdemos/Makefile
> +++ b/progs/xdemos/Makefile
> @@ -53,17 +53,18 @@ EXTRA_PROGS = \
>
>  ##### RULES #####
>
> -.SUFFIXES:
> -.SUFFIXES: .c
> +.o: $(LIB_DEP)
> +       $(APP_CC) $(LDFLAGS) $< $(LIBS) -o $@
>
> -.c: $(LIB_DEP)
> -       $(APP_CC) -I$(INCDIR) $(X11_INCLUDES) $(CFLAGS) $(LDFLAGS) $< $(LIBS) -o $@
> +.c.o:
> +       $(APP_CC) -I$(INCDIR) $(X11_INCLUDES) $(CFLAGS) $< -c -o $@
>
>
>  ##### TARGETS #####
>
>  default: $(PROGS)
>
> +$(PROGS): $(PROGS:%=%.o)

Is this necessary? I would think the prereq would be picked up
implicitly like the .c from the .o.

>
>  extra: $(EXTRA_PROGS)
>
> @@ -74,45 +75,29 @@ clean:
>
>
>  # special cases
> +pbutil.o: pbutil.h
> +pbinfo.o: pbutil.h
>  pbinfo: pbinfo.o pbutil.o
>        $(APP_CC) $(CFLAGS) $(LDFLAGS) pbinfo.o pbutil.o $(LIBS) -o $@
>
> +pbdemo.o: pbutil.h
>  pbdemo: pbdemo.o pbutil.o
>        $(APP_CC) $(CFLAGS) $(LDFLAGS) pbdemo.o pbutil.o $(LIBS) -o $@
>
> -pbinfo.o: pbinfo.c pbutil.h
> -       $(APP_CC) -c -I. -I$(INCDIR) $(X11_INCLUDES) $(CFLAGS) pbinfo.c
> -
> -pbdemo.o: pbdemo.c pbutil.h
> -       $(APP_CC) -c -I. -I$(INCDIR) $(X11_INCLUDES) $(CFLAGS) pbdemo.c
> -
> -pbutil.o: pbutil.c pbutil.h
> -       $(APP_CC) -c -I. -I$(INCDIR) $(X11_INCLUDES) $(CFLAGS) pbutil.c
> -
> +glxgears_fbconfig.o: pbutil.h
>  glxgears_fbconfig: glxgears_fbconfig.o pbutil.o
>        $(APP_CC) $(CFLAGS) $(LDFLAGS) glxgears_fbconfig.o pbutil.o $(LIBS) -o $@
>
> -glxgears_fbconfig.o: glxgears_fbconfig.c pbutil.h
> -       $(APP_CC) -I$(INCDIR) $(X11_INCLUDES) $(CFLAGS) -c -I. $(CFLAGS) glxgears_fbconfig.c
> -
> +xuserotfont.o: xuserotfont.h
> +xrotfontdemo.o: xuserotfont.h
>  xrotfontdemo: xrotfontdemo.o xuserotfont.o
>        $(APP_CC) $(CFLAGS) $(LDFLAGS) xrotfontdemo.o xuserotfont.o $(LIBS) -o $@
>
> -xuserotfont.o: xuserotfont.c xuserotfont.h
> -       $(APP_CC) -c -I. -I$(INCDIR) $(X11_INCLUDES) $(CFLAGS) xuserotfont.c
> -
> -xrotfontdemo.o: xrotfontdemo.c xuserotfont.h
> -       $(APP_CC) -c -I. -I$(INCDIR) $(X11_INCLUDES) $(CFLAGS) xrotfontdemo.c
> -
> +ipc.o: ipc.h
> +corender.o: ipc.h
>  corender: corender.o ipc.o
>        $(APP_CC) $(CFLAGS) $(LDFLAGS) corender.o ipc.o $(LIBS) -o $@
>
> -corender.o: corender.c ipc.h
> -       $(APP_CC) -c -I. -I$(INCDIR) $(X11_INCLUDES) $(CFLAGS) corender.c
> -
> -ipc.o: ipc.c ipc.h
> -       $(APP_CC) -c -I. -I$(INCDIR) $(X11_INCLUDES) $(CFLAGS) ipc.c
> -
> -yuvrect_client: yuvrect_client.c
> -       $(APP_CC) -I$(INCDIR) $(X11_INCLUDES) $(CFLAGS) $< $(LDFLAGS) $(LIBS) -l$(GLU_LIB) -o $@
> +yuvrect_client: yuvrect_client.o
> +       $(APP_CC) $< $(LDFLAGS) $(LIBS) -l$(GLU_LIB) -o $@

You dropped the CFLAGS from this last one, which can break when people
put things like -m32 there.

--
Dan

Re: [Mesa3d-dev] [PATCH 1/2] xdemos: Fix a build failure for non-autoconf configs

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

On Thu, Apr 1, 2010 at 12:35 PM, Jeremy Huddleston
<jer...@fr...> wrote:
>
> Signed-off-by: Jeremy Huddleston <jer...@ap...>
> ---
>  progs/xdemos/Makefile |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/progs/xdemos/Makefile b/progs/xdemos/Makefile
> index e87d55d..d5c627a 100644
> --- a/progs/xdemos/Makefile
> +++ b/progs/xdemos/Makefile
> @@ -11,7 +11,7 @@ LIB_DEP = $(TOP)/$(LIB_DIR)/$(GL_LIB_NAME)
>  # Add X11 and pthread libs to satisfy GNU gold.
>  APP_LIB_DEPS += -lX11 -lpthread
>
> -LIBS = -L$(TOP)/$(LIB_DIR) -l$(GL_LIB) -L$(libdir) $(APP_LIB_DEPS)
> +LIBS = -L$(TOP)/$(LIB_DIR) -l$(GL_LIB) -L$(INSTALL_LIB_DIR) $(APP_LIB_DEPS)

Is this against master? We changed this to use $(X11_LIBS), which is
unfortunately only filled in by configure. BTW, what config are you
using, and what prevents you from using autoconf?

--
Dan

[Mesa3d-dev] [PATCH 2/2] xdemos: Build object files first

[Jeremy H. <jer...@fr...>]

This helps debugging on darwin.

Signed-off-by: Jeremy Huddleston <jer...@ap...>
---
 progs/xdemos/Makefile |   45 +++++++++++++++------------------------------
 1 files changed, 15 insertions(+), 30 deletions(-)

diff --git a/progs/xdemos/Makefile b/progs/xdemos/Makefile
index d5c627a..29cba0c 100644
--- a/progs/xdemos/Makefile
+++ b/progs/xdemos/Makefile
@@ -53,17 +53,18 @@ EXTRA_PROGS = \
 
 ##### RULES #####
 
-.SUFFIXES:
-.SUFFIXES: .c
+.o: $(LIB_DEP)
+	$(APP_CC) $(LDFLAGS) $< $(LIBS) -o $@
 
-.c: $(LIB_DEP)
-	$(APP_CC) -I$(INCDIR) $(X11_INCLUDES) $(CFLAGS) $(LDFLAGS) $< $(LIBS) -o $@
+.c.o:
+	$(APP_CC) -I$(INCDIR) $(X11_INCLUDES) $(CFLAGS) $< -c -o $@
 
 
 ##### TARGETS #####
 
 default: $(PROGS)
 
+$(PROGS): $(PROGS:%=%.o)
 
 extra: $(EXTRA_PROGS)
 
@@ -74,45 +75,29 @@ clean:
 
 
 # special cases
+pbutil.o: pbutil.h
+pbinfo.o: pbutil.h
 pbinfo: pbinfo.o pbutil.o
 	$(APP_CC) $(CFLAGS) $(LDFLAGS) pbinfo.o pbutil.o $(LIBS) -o $@
 
+pbdemo.o: pbutil.h
 pbdemo: pbdemo.o pbutil.o
 	$(APP_CC) $(CFLAGS) $(LDFLAGS) pbdemo.o pbutil.o $(LIBS) -o $@
 
-pbinfo.o: pbinfo.c pbutil.h
-	$(APP_CC) -c -I. -I$(INCDIR) $(X11_INCLUDES) $(CFLAGS) pbinfo.c
-
-pbdemo.o: pbdemo.c pbutil.h
-	$(APP_CC) -c -I. -I$(INCDIR) $(X11_INCLUDES) $(CFLAGS) pbdemo.c
-
-pbutil.o: pbutil.c pbutil.h
-	$(APP_CC) -c -I. -I$(INCDIR) $(X11_INCLUDES) $(CFLAGS) pbutil.c
-
+glxgears_fbconfig.o: pbutil.h
 glxgears_fbconfig: glxgears_fbconfig.o pbutil.o
 	$(APP_CC) $(CFLAGS) $(LDFLAGS) glxgears_fbconfig.o pbutil.o $(LIBS) -o $@
 
-glxgears_fbconfig.o: glxgears_fbconfig.c pbutil.h
-	$(APP_CC) -I$(INCDIR) $(X11_INCLUDES) $(CFLAGS) -c -I. $(CFLAGS) glxgears_fbconfig.c
-
+xuserotfont.o: xuserotfont.h
+xrotfontdemo.o: xuserotfont.h
 xrotfontdemo: xrotfontdemo.o xuserotfont.o
 	$(APP_CC) $(CFLAGS) $(LDFLAGS) xrotfontdemo.o xuserotfont.o $(LIBS) -o $@
 
-xuserotfont.o: xuserotfont.c xuserotfont.h
-	$(APP_CC) -c -I. -I$(INCDIR) $(X11_INCLUDES) $(CFLAGS) xuserotfont.c
-
-xrotfontdemo.o: xrotfontdemo.c xuserotfont.h
-	$(APP_CC) -c -I. -I$(INCDIR) $(X11_INCLUDES) $(CFLAGS) xrotfontdemo.c
-
+ipc.o: ipc.h
+corender.o: ipc.h
 corender: corender.o ipc.o
 	$(APP_CC) $(CFLAGS) $(LDFLAGS) corender.o ipc.o $(LIBS) -o $@
 
-corender.o: corender.c ipc.h
-	$(APP_CC) -c -I. -I$(INCDIR) $(X11_INCLUDES) $(CFLAGS) corender.c
-
-ipc.o: ipc.c ipc.h
-	$(APP_CC) -c -I. -I$(INCDIR) $(X11_INCLUDES) $(CFLAGS) ipc.c
-
-yuvrect_client: yuvrect_client.c
-	$(APP_CC) -I$(INCDIR) $(X11_INCLUDES) $(CFLAGS) $< $(LDFLAGS) $(LIBS) -l$(GLU_LIB) -o $@
+yuvrect_client: yuvrect_client.o
+	$(APP_CC) $< $(LDFLAGS) $(LIBS) -l$(GLU_LIB) -o $@
 
-- 
1.7.0.3

[Mesa3d-dev] [PATCH 1/2] xdemos: Fix a build failure for non-autoconf configs

[Jeremy H. <jer...@fr...>]

Signed-off-by: Jeremy Huddleston <jer...@ap...>
---
 progs/xdemos/Makefile |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/progs/xdemos/Makefile b/progs/xdemos/Makefile
index e87d55d..d5c627a 100644
--- a/progs/xdemos/Makefile
+++ b/progs/xdemos/Makefile
@@ -11,7 +11,7 @@ LIB_DEP = $(TOP)/$(LIB_DIR)/$(GL_LIB_NAME)
 # Add X11 and pthread libs to satisfy GNU gold.
 APP_LIB_DEPS += -lX11 -lpthread
 
-LIBS = -L$(TOP)/$(LIB_DIR) -l$(GL_LIB) -L$(libdir) $(APP_LIB_DEPS)
+LIBS = -L$(TOP)/$(LIB_DIR) -l$(GL_LIB) -L$(INSTALL_LIB_DIR) $(APP_LIB_DEPS)
 
 PROGS = \
 	corender \
-- 
1.7.0.3

Re: [Mesa3d-dev] [PATCH] Add -L$(libdir) for xdemos and egl so that the right libX11 is found

[Jeremy H. <jer...@fr...>]

This breaks platforms not using autoconf.  You should change it to -L$(INSTALL_LIB_DIR)


On Mar 11, 2010, at 20:09, Jeff Smith wrote:

> 
> 
> 
> 
> <0003-Add-L-libdir-for-xdemos-and-egl-so-that-the-right.patch>------------------------------------------------------------------------------
> 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 (master): gallium/util: add fast half float conversion functions

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

> This constructor scheme is not working for me. I think that's because
> there isn't any symbol here that's used elsewhere, hence the linker is
> not linking this file.

I replaced the system with a different mechanism.

It should now work correctly, but only GCC and MSVC are supported, and
the latter is untested.

> Please put copyright headers. *Especially* when basing your work from
> external references, as it gives the impression that this code was
> copied, and not your own creation.

Done: the code was a reimplementation from scratch of the code
provided by them, with slight changes.

Re: [Mesa3d-dev] gallium "raw" interfaces

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

On Thu, Apr 1, 2010 at 1:32 AM, Luca Barbieri <luc...@gm...> wrote:
>> Once MS changes interfaces, then there's _no advantage_ to using DX10
>> internally, regardless of what WINE does, and one might as well use
>> OpenGL.  Wine doesn't change that.
>
> [resent to ML, inadvertently replied only to Miles]
>
> Note that my proposal was not to use DirectX 10 internally, but rather
> to expose DirectX 10 and promote it initially as an API to test
> Gallium and later as the preferred Linux graphics API instead of
> OpenGL, for the technical reason that a DirectX 10 over Gallium
> implementation carries much less performance overhead than an OpenGL
> implementation and is much simpler, due to the superior design of
> DirectX 10.
>
> Using an extended version of DirectX 10 internally could also be an
> option, but I don't think it's worth doing that right now and likely
> it's not worth at all.
>
> Also note that Microsoft does not use DirectX 10 or 11 internally
> either, but rather uses the "DirectX 10 DDI" or "DirectX 10 Device
> Driver Interface", which is also publicly documented.
>
> The last time Microsoft did an incompatible interface change (DX10),
> it was to move away from fixed pipeline support with scattered state
> towards a shader-only pipeline with constant state objects.
>
> Exactly the same change was achieved by the move from the classic Mesa
> architecture to the Gallium architecture: you could think of the move
> to Gallium as switching to something like DX10 internally, done purely
> for technical reasons, partially the same as the ones that prompted
> Microsoft to make the transition.
>
> Actually, while this is not generally explicitly stated by Gallium
> designers, Gallium itself is generally evolving towards being closer
> to DirectX 10.
> The biggest deviations are additional features needed to support
> OpenGL features not included in DirectX 10.
>
> For instance, looking at recent changes:
> - Vertex element CSOs, recently added, are equivalent to DX10 input layouts
> - Sampler views, also recently added, are equivalent to DX10 shared
> resource views
> - Doing transfers per-context (recent work by Keith Whitwell) is what DX10 does
> - Having a "resource" concept (also recent work by Keith Whitwell) is
> what DX10 does
> - Gallium format values where changed from self-describing to a set of
> stock values like DX10
> - Gallium format names where later changed and made identical to DX10
> ones (except for the fact that the names of the former start with
> PIPE_FORMAT_ and the ones of the latter with DXGI_FORMAT_, and the
> enumerated values are different)
> - It has been decided to follow the DX9 SM3/DX10 model for shader
> semantic linkage as opposed to the OpenGL one
>
> I recently systematically compared Gallium and DirectX 10, and found
> them to be mostly equivalent, where the exceptions were usually either
> additional features Gallium had for the sake of OpenGL, or Gallium
> misdesigns that are being changed or looked into.
>
> This is not likely for the sake of imitating Microsoft, but just
> because they made a good design, having had made the decision to
> redesign the whole API from scratch when making DirectX 10.
> It's also probably because VMWare is apparently funding DirectX 10
> support over Gallium, which obviously makes all discrepancies evident
> for people working on that, and those are generally because DirectX 10
> is better, leading those people to improve the Gallium design taking
> inspiration from DirectX 10.
>
> Presumably if Microsoft were to change interfaces incompatibly again
> (notice that DX11 is a compatible change), Mesa would probably benefit
> from introducing a further abstraction layer similar to new Microsoft
> interface and have a Gallium->NewLayer module, since such a change
> would most likely be a result of a paradigm shift in graphics hardware
> itself (e.g. a switch to fully software-based GPUs like Larrabee).
>
> Also, unless Microsoft holds patents to DirectX 10 (which would be a
> showstopper, even though Gallium may violate them anyway), I don't see
> any difference from having to implement DirectX 10 or OpenGL, or any
> difference in "openness" of the APIs.
> It is indeed possible to participate in the ARB standardization
> process and some Mesa contributors/leaders do, but I'm not sure
> whether this is particularly advantageous: decisions that work well
> for Microsoft and Windows are also likely to work well for Linux/Mesa
> since the hardware is the same and the software works mostly
> equivalently.
>
> And should some decisions not work well, it is technically trivial to
> provide an alternative API.

Is it really so surprising that an API designed to expose a generic,
programmable, shaderful pipeline (Gallium) fits well to multiple APIs
based on the same concept (D3D10, OGL 2.x)?

-- 
When the facts change, I change my mind. What do you do, sir? ~ Keynes

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

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

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

Hi Luca,

   > Should be fixed now.  BTW, if it is still not compiling due to
   > the __sync* issues, try adding CFLAGS="-march=v9" to the build:
   > it should fix that.

Thanks, both are fixed now.

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

Re: [Mesa3d-dev] Mesa (master): gallium/util: add fast half float conversion functions

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

On Thu, 2010-04-01 at 04:33 -0700, Micha?? Kr??l wrote:
> Module: Mesa
> Branch: master
> Commit: 3ff175d6de89ad92d167362355501f99d06f0f97
> URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=3ff175d6de89ad92d167362355501f99d06f0f97
> 
> Author: Luca Barbieri <lu...@lu...>
> Date:   Wed Mar 24 18:12:45 2010 +0100
> 
> gallium/util: add fast half float conversion functions
> 
> This adds a fast half float conversion facility to Gallium.
> 
> Mesa already contains such a facility, but using a much worse algorithm.
> 
> This one is an implementation of
> www.fox-toolkit.org/ftp/fasthalffloatconversion.pdf
> and uses a branch-less algorithm with some lookup tables small enough
> to fit in the L1 cache.
> 
> Ideally, Mesa should start using these functions too, but I'm not sure
> how to arrange that with the current build system.
> 
> A new "u_gctors.cpp" is added that defines a global C++ constructor
> allowing to initialize to conversion lookup tables at library init.
> 
> ---
> 
>  src/gallium/auxiliary/Makefile          |    4 +
>  src/gallium/auxiliary/util/u_gctors.cpp |   17 ++++
>  src/gallium/auxiliary/util/u_half.c     |  123 +++++++++++++++++++++++++++++++
>  src/gallium/auxiliary/util/u_half.h     |   55 ++++++++++++++
>  4 files changed, 199 insertions(+), 0 deletions(-)
[..]
> diff --git a/src/gallium/auxiliary/util/u_gctors.cpp b/src/gallium/auxiliary/util/u_gctors.cpp
> new file mode 100644
> index 0000000..9ea9819
> --- /dev/null
> +++ b/src/gallium/auxiliary/util/u_gctors.cpp
> @@ -0,0 +1,17 @@
> +/* this file uses the C++ global constructor mechanism to automatically
> +   initialize global data
> +
> +   __attribute__((constructor)) allows to do this in C, but is GCC-only
> +*/
> +
> +extern "C" void util_half_init_tables(void);
> +
> +struct util_gctor_t
> +{
> +	util_gctor_t()
> +	{
> +		util_half_init_tables();
> +	}
> +};
> +
> +static struct util_gctor_t util_gctor;

This constructor scheme is not working for me. I think that's because
there isn't any symbol here that's used elsewhere, hence the linker is
not linking this file.

> diff --git a/src/gallium/auxiliary/util/u_half.c b/src/gallium/auxiliary/util/u_half.c
> new file mode 100644
> index 0000000..8865acb
> --- /dev/null
> +++ b/src/gallium/auxiliary/util/u_half.c
> @@ -0,0 +1,123 @@
> +#include "util/u_half.h"
> +
> +/* see www.fox-toolkit.org/ftp/fasthalffloatconversion.pdf
> + * "Fast Half Float Conversions" by Jeroen van der Zijp, Nov 2008
> + */
> +
> +/* Note that using a 64K * 4 table is a terrible idea since it will not fit
> + * in the L1 cache and will massively pollute the L2 cache as well
> + *
> + * These should instead fit in the L1 cache.
> + *
> + * TODO: we could use a denormal bias table instead of the mantissa/offset
> + * tables: this would reduce the L1 cache usage from 8704 to 2304 bytes
> + * but would involve more computation
> + *
> + * Note however that if denormals are never encountered, the L1 cache usage
> + * is only about 4608 bytes anyway.
> + */

Please put copyright headers. *Especially* when basing your work from
external references, as it gives the impression that this code was
copied, and not your own creation.

Jose

Re: [Mesa3d-dev] Gallium half float conversion/support

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

W dniu 2010-04-01 06:05, Luca Barbieri pisze:
> [sent to ML too]
>
> Michal,
> I noticed you made some commits related to half float support in Gallium.
>
> I had already done this work and implemented a fast conversion
> algorithm capable of handling all cases based on a paper cited in the
> commit, but hadn't gotten around to proposing it yet.
>
> I created a "gallium-fast-half-float" branch and put my work there, so
> it may be useful to you.
> Feel free to merge, rebase and/or adapt it against Mesa master.
>
>    
I cherry picked the relevant code from the branch and adapted it for 
gallium. Big thanks!


> The conversion function itself has been tested separately from
> Gallium, but I haven't tested softpipe on fp16 data.
>
> Ideally we should find a way to have Mesa use this improved converter
> instead of the one it currently uses, but I'm not sure how to arrange
> this with the current buildsystem.
>    

Re: [Mesa3d-dev] gallium "raw" interfaces

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

> Once MS changes interfaces, then there's _no advantage_ to using DX10
> internally, regardless of what WINE does, and one might as well use
> OpenGL.  Wine doesn't change that.

[resent to ML, inadvertently replied only to Miles]

Note that my proposal was not to use DirectX 10 internally, but rather
to expose DirectX 10 and promote it initially as an API to test
Gallium and later as the preferred Linux graphics API instead of
OpenGL, for the technical reason that a DirectX 10 over Gallium
implementation carries much less performance overhead than an OpenGL
implementation and is much simpler, due to the superior design of
DirectX 10.

Using an extended version of DirectX 10 internally could also be an
option, but I don't think it's worth doing that right now and likely
it's not worth at all.

Also note that Microsoft does not use DirectX 10 or 11 internally
either, but rather uses the "DirectX 10 DDI" or "DirectX 10 Device
Driver Interface", which is also publicly documented.

The last time Microsoft did an incompatible interface change (DX10),
it was to move away from fixed pipeline support with scattered state
towards a shader-only pipeline with constant state objects.

Exactly the same change was achieved by the move from the classic Mesa
architecture to the Gallium architecture: you could think of the move
to Gallium as switching to something like DX10 internally, done purely
for technical reasons, partially the same as the ones that prompted
Microsoft to make the transition.

Actually, while this is not generally explicitly stated by Gallium
designers, Gallium itself is generally evolving towards being closer
to DirectX 10.
The biggest deviations are additional features needed to support
OpenGL features not included in DirectX 10.

For instance, looking at recent changes:
- Vertex element CSOs, recently added, are equivalent to DX10 input layouts
- Sampler views, also recently added, are equivalent to DX10 shared
resource views
- Doing transfers per-context (recent work by Keith Whitwell) is what DX10 does
- Having a "resource" concept (also recent work by Keith Whitwell) is
what DX10 does
- Gallium format values where changed from self-describing to a set of
stock values like DX10
- Gallium format names where later changed and made identical to DX10
ones (except for the fact that the names of the former start with
PIPE_FORMAT_ and the ones of the latter with DXGI_FORMAT_, and the
enumerated values are different)
- It has been decided to follow the DX9 SM3/DX10 model for shader
semantic linkage as opposed to the OpenGL one

I recently systematically compared Gallium and DirectX 10, and found
them to be mostly equivalent, where the exceptions were usually either
additional features Gallium had for the sake of OpenGL, or Gallium
misdesigns that are being changed or looked into.

This is not likely for the sake of imitating Microsoft, but just
because they made a good design, having had made the decision to
redesign the whole API from scratch when making DirectX 10.
It's also probably because VMWare is apparently funding DirectX 10
support over Gallium, which obviously makes all discrepancies evident
for people working on that, and those are generally because DirectX 10
is better, leading those people to improve the Gallium design taking
inspiration from DirectX 10.

Presumably if Microsoft were to change interfaces incompatibly again
(notice that DX11 is a compatible change), Mesa would probably benefit
from introducing a further abstraction layer similar to new Microsoft
interface and have a Gallium->NewLayer module, since such a change
would most likely be a result of a paradigm shift in graphics hardware
itself (e.g. a switch to fully software-based GPUs like Larrabee).

Also, unless Microsoft holds patents to DirectX 10 (which would be a
showstopper, even though Gallium may violate them anyway), I don't see
any difference from having to implement DirectX 10 or OpenGL, or any
difference in "openness" of the APIs.
It is indeed possible to participate in the ARB standardization
process and some Mesa contributors/leaders do, but I'm not sure
whether this is particularly advantageous: decisions that work well
for Microsoft and Windows are also likely to work well for Linux/Mesa
since the hardware is the same and the software works mostly
equivalently.

And should some decisions not work well, it is technically trivial to
provide an alternative API.

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

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

Should be fixed now.

BTW, if it is still not compiling due to the __sync* issues, try
adding CFLAGS="-march=v9" to the build: it should fix that.

[Mesa3d-dev] Gallium half float conversion/support

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

[sent to ML too]

Michal,
I noticed you made some commits related to half float support in Gallium.

I had already done this work and implemented a fast conversion
algorithm capable of handling all cases based on a paper cited in the
commit, but hadn't gotten around to proposing it yet.

I created a "gallium-fast-half-float" branch and put my work there, so
it may be useful to you.
Feel free to merge, rebase and/or adapt it against Mesa master.

The conversion function itself has been tested separately from
Gallium, but I haven't tested softpipe on fp16 data.

Ideally we should find a way to have Mesa use this improved converter
instead of the one it currently uses, but I'm not sure how to arrange
this with the current buildsystem.

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

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

Hi,

http://tinderbox.x.org/builds/2010-03-31-0023/logs/libGL/#build

swrastg_dri.so.tmp: undefined reference to `util_bswap8'

(New as of ~12 hours ago.)

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

Re: [Mesa3d-dev] gallium "raw" interfaces

[Miles B. <mi...@gn...>]

On Thu, Apr 1, 2010 at 12:28 AM, Xavier Bestel <xav...@fr...> wrote:
> On Wed, 2010-03-31 at 13:29 +0900, Miles Bader wrote:
>> Luca Barbieri <luc...@gm...> writes:
>> > In fact, given the Gallium architecture, it may even make sense to
>> > support a variant of DirectX 10 as the main Mesa/Gallium API on all
>> > platfoms, instead of OpenGL.
>>
>> The apparent benefit would seem to be greater compatibility with
>> software written for windows -- but that benefit is unlikely to remain,
>> as MS basically changes their interfaces drastically with each major
>> revision.
>
> WINE can deal with that. The real showstopper is that WINE has to also
> work on MacOS X and Linux + NVIDIA blob, where Gallium is unavailable.

"Wine can deal with that", how?

Once MS changes interfaces, then there's _no advantage_ to using DX10
internally, regardless of what WINE does, and one might as well use
OpenGL.  Wine doesn't change that.

Given that OpenGL has other advantages (portable, publicly accessible
standardization proces, etc), adopting DX10 would seem pointless and
misguided.

-Miles

-- 
Do not taunt Happy Fun Ball.