headers
bugzilla-daemon | 1 Mar 2009 23:04

[Bug 20413] New: Mac OS build broken

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

           Summary: Mac OS build broken
           Product: Mesa
           Version: unspecified
          Platform: x86 (IA32)
        OS/Version: Mac OS X (All)
            Status: NEW
          Severity: critical
          Priority: medium
         Component: Other
        AssignedTo: mesa3d-dev <at> lists.sourceforge.net
        ReportedBy: vlee <at> vmware.com

The git/master build of Mesa on Mac OS is currently broken.

Mesa-7.3 - ok
Mesa-7.5-devel-20090205 - ok
Mesa-7.5-devel-20090209 - ok
Mesa-7.5-devel-20090224 - bad

gcc -c -I../../../include -I../../../src/mesa/glapi -g -O2 -Wall
-Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing  -fno-common  
-DUSE_XSHM -D_EGL_PLATFORM_X=1 eglapi.c -o eglapi.o
In file included from ../../../include/EGL/egl.h:13,
                 from egltypedefs.h:6,
                 from eglcontext.h:6,
                 from eglapi.c:36:
../../../include/EGL/eglplatform.h:87: error: syntax error before
‘EGLNativeDisplayType’
(Continue reading)

Permalink | Reply | 4 comments |
headers
Pauli Nieminen | 2 Mar 2009 02:04
Picon

Re: Fix dri r200 driver debug output not to lock drm module complitely if debug output is going to terminal

Here is improved implementation for buffered debug output when
hardware is locked. This version is untested because conversion is
still not ready. I just want some feed back if whole idea is shot down
and it is worthless to continue converting debug output.

It includes all functional parts but is far from ready because many
parts of mesa are still waiting to be converted.

Basic functionality is included in first patch. 11th patch includes
change to first and only dri driver converted so far. All less
interesting patches are in patches.tgz

list of patch files:
0001-Buffered-debbug-output-to-mesa.patch
0002-Convert-messa-main-to-use-new-debug-output-functiona.patch
0003-Convert-mesa-math-to-new-debug-output-format.patch
0004-Convert-swrast-to-use-new-debug-output.patch
0005-Convert-shader-compiler-to-use-new-debug-output-form.patch
0006-Convert-state_tracker-to-use-new-debug-functions.patch
0007-convert-tnl-to-use-new-debug-functions.patch
0008-Convert-vf-to-use-new-debug-functions.patch
0009-Convert-vbo-to-use-new-debug-functions.patch
0010-Convert-tnl_dd-to-use-new-debug-functions.patch
0011--Make-sis-dri-driver-to-use-new-debug-functions.patch
0012-Fixing-random-conversion-mistakes.patch

Pauli
Attachment (0001-Buffered-debbug-output-to-mesa.patch): text/x-diff, 7416 bytes
Attachment (0011--Make-sis-dri-driver-to-use-new-debug-functions.patch): text/x-diff, 17 KiB
(Continue reading)

Permalink | Reply | 2 comments |
headers
bugzilla-daemon | 2 Mar 2009 04:27

[Bug 20413] Mac OS build broken

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

--- Comment #1 from Dan Nicholson <dbn.lists <at> gmail.com>  2009-03-01 19:27:10 PST ---
Created an attachment (id=23428)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=23428)
Define Xlib types for Mac EGL, too

I think that this is because EGL has only recently been enabled. We can either
disable the EGL build on Mac or fix up eglplatform.h to work on Mac. I've never
built mesa on mac, but I'm guessing that EGL will just use Xlib like Linux. Can
you try this patch?

Probably this needs some attention from the Mac X people.

--

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

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 2 Mar 2009 04:40

[Bug 20413] Mac OS build broken

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

--- Comment #2 from Vinson Lee <vlee <at> vmware.com>  2009-03-01 19:40:51 PST ---
% make
Making sources for autoconf
(cd drivers && make)
make[4]: Nothing to be done for `default'.
make[5]: Nothing to be done for `osmesa8'.
/bin/sh ../../../bin/mklib -o EGL -linker 'gcc' -ldflags '' \
                -major 1 -minor 0 \
                -install ../../../lib \
                 -L/usr/X11/lib -lX11 -lXau -lXdmcp     eglapi.o eglconfig.o
eglconfigutil.o eglcontext.o egldisplay.o egldriver.o eglglobals.o egllog.o
eglhash.o eglmisc.o eglmode.o eglscreen.o eglstring.o eglsurface.o eglx.o
mklib: Making Darwin shared library:  libEGL.1.0.dylib
mklib: Installing libEGL.1.0.dylib libEGL.1.dylib libEGL.dylib in ../../../lib
/bin/sh ../../../../bin/mklib -o demodriver.so -noprefix -linker 'gcc' \
                -ldflags '' -install ../../../../lib \
                demo.o
mklib: Making Darwin shared library:  libdemodriver.so.1.0.dylib
Undefined symbols:
  "__eglAddScreen", referenced from:
      _demoInitialize in demo.o
  "__eglRemoveContext", referenced from:
      _demoDestroyContext in demo.o
  "__eglLookupDisplay", referenced from:
      _demoInitialize in demo.o
  "__eglInitConfig", referenced from:
      _demoInitialize in demo.o
  "__eglError", referenced from:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stephane Marchesin | 2 Mar 2009 09:17
Picon
Picon
Favicon

Re: Fix dri r200 driver debug output not to lock drm module complitely if debug output is going to terminal

On Mon, Mar 2, 2009 at 02:04, Pauli Nieminen <suokkos <at> gmail.com> wrote:
> Here is improved implementation for buffered debug output when
> hardware is locked. This version is untested because conversion is
> still not ready. I just want some feed back if whole idea is shot down
> and it is worthless to continue converting debug output.
>
> It includes all functional parts but is far from ready because many
> parts of mesa are still waiting to be converted.
>
> Basic functionality is included in first patch. 11th patch includes
> change to first and only dri driver converted so far. All less
> interesting patches are in patches.tgz
>
> list of patch files:
> 0001-Buffered-debbug-output-to-mesa.patch
> 0002-Convert-messa-main-to-use-new-debug-output-functiona.patch
> 0003-Convert-mesa-math-to-new-debug-output-format.patch
> 0004-Convert-swrast-to-use-new-debug-output.patch
> 0005-Convert-shader-compiler-to-use-new-debug-output-form.patch
> 0006-Convert-state_tracker-to-use-new-debug-functions.patch
> 0007-convert-tnl-to-use-new-debug-functions.patch
> 0008-Convert-vf-to-use-new-debug-functions.patch
> 0009-Convert-vbo-to-use-new-debug-functions.patch
> 0010-Convert-tnl_dd-to-use-new-debug-functions.patch
> 0011--Make-sis-dri-driver-to-use-new-debug-functions.patch
> 0012-Fixing-random-conversion-mistakes.patch
>

Why add it to the whole mesa ? This problem is not affecting all
drivers, while this is adding a level of hack/complexity though. At
(Continue reading)

Permalink | Reply | 0 comments |
headers
Keith Whitwell | 2 Mar 2009 11:14
Favicon

Re: Fix dri r200 driver debug output not to lock drm module complitely if debug output is going to terminal

On Sun, 2009-03-01 at 17:04 -0800, Pauli Nieminen wrote:
> Here is improved implementation for buffered debug output when
> hardware is locked. This version is untested because conversion is
> still not ready. I just want some feed back if whole idea is shot down
> and it is worthless to continue converting debug output.
> 
> It includes all functional parts but is far from ready because many
> parts of mesa are still waiting to be converted.
> 
> Basic functionality is included in first patch. 11th patch includes
> change to first and only dri driver converted so far. All less
> interesting patches are in patches.tgz
> 
> list of patch files:
> 0001-Buffered-debbug-output-to-mesa.patch
> 0002-Convert-messa-main-to-use-new-debug-output-functiona.patch
> 0003-Convert-mesa-math-to-new-debug-output-format.patch
> 0004-Convert-swrast-to-use-new-debug-output.patch
> 0005-Convert-shader-compiler-to-use-new-debug-output-form.patch
> 0006-Convert-state_tracker-to-use-new-debug-functions.patch
> 0007-convert-tnl-to-use-new-debug-functions.patch
> 0008-Convert-vf-to-use-new-debug-functions.patch
> 0009-Convert-vbo-to-use-new-debug-functions.patch
> 0010-Convert-tnl_dd-to-use-new-debug-functions.patch
> 0011--Make-sis-dri-driver-to-use-new-debug-functions.patch
> 0012-Fixing-random-conversion-mistakes.patch

Actually I'm pretty much against this, as it will break the typical
debugging scenario that everybody has been using for many years -- ssh
in from another machine and run gdb in the ssh session.  If prints
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matthias Hopf | 2 Mar 2009 12:16
Picon

Re: Indirect rendering to old Xservers...

Hey Ian,

On Feb 27, 09 17:13:41 -0800, Ian Romanick wrote:
> Matthias Hopf wrote:
> > I haven't noticed until recently (due to a bug opened against our
> > openSUSE 11.1) that indirect rendering via GLX doesn't work any more
> > when an older Xserver is involved.
> 
> Can you be more specific?  What commands don't work?  Can you run
> glxinfo on one machine using the display on another?

You can run it, but the output doesn't make any sense, because it
doesn't get reasonable visuals:

gkar:~ # glxinfo
name of display: localhost:10.0
Error: couldn't find RGB GLX visual

   visual  x  bf lv rg d st colorbuffer ax dp st accumbuffer  ms  cav
 id dep cl sp sz l  ci b ro  r  g  b  a bf th cl  r  g  b  a ns b eat
----------------------------------------------------------------------
0x23 24 tc  1  0  0 c  .  .  0  0  0  0  0  0  0  0  0  0  0  0 0 None
0x24 24 tc  1  0  0 c  .  .  0  0  0  0  0  0  0  0  0  0  0  0 0 None
0x25 24 tc  1  0  0 c  .  .  0  0  0  0  0  0  0  0  0  0  0  0 0 None
0x26 24 tc  1  0  0 c  .  .  0  0  0  0  0  0  0  0  0  0  0  0 0 None
0x27 24 dc  1  0  0 c  .  .  0  0  0  0  0  0  0  0  0  0  0  0 0 None
0x28 24 dc  1  0  0 c  .  .  0  0  0  0  0  0  0  0  0  0  0  0 0 None
0x29 24 dc  1  0  0 c  .  .  0  0  0  0  0  0  0  0  0  0  0  0 0 None
0x2a 24 dc  1  0  0 c  .  .  0  0  0  0  0  0  0  0  0  0  0  0 0 None
(Continue reading)

Permalink | Reply | 2 comments |
headers
Michel Dänzer | 2 Mar 2009 15:28

Re: Indirect rendering to old Xservers...

On Mon, 2009-03-02 at 12:16 +0100, Matthias Hopf wrote:
> 
> On Feb 27, 09 17:13:41 -0800, Ian Romanick wrote:
> > Matthias Hopf wrote:
> > > I haven't noticed until recently (due to a bug opened against our
> > > openSUSE 11.1) that indirect rendering via GLX doesn't work any more
> > > when an older Xserver is involved.
> > 
> > Can you be more specific?  What commands don't work?  Can you run
> > glxinfo on one machine using the display on another?
> 
> You can run it, but the output doesn't make any sense, because it
> doesn't get reasonable visuals:
> 
> gkar:~ # glxinfo
> name of display: localhost:10.0
> Error: couldn't find RGB GLX visual
> 
>    visual  x  bf lv rg d st colorbuffer ax dp st accumbuffer  ms  cav
>  id dep cl sp sz l  ci b ro  r  g  b  a bf th cl  r  g  b  a ns b eat
> ----------------------------------------------------------------------
> 0x23 24 tc  1  0  0 c  .  .  0  0  0  0  0  0  0  0  0  0  0  0 0 None
> 0x24 24 tc  1  0  0 c  .  .  0  0  0  0  0  0  0  0  0  0  0  0 0 None
> 0x25 24 tc  1  0  0 c  .  .  0  0  0  0  0  0  0  0  0  0  0  0 0 None
> 0x26 24 tc  1  0  0 c  .  .  0  0  0  0  0  0  0  0  0  0  0  0 0 None
> 0x27 24 dc  1  0  0 c  .  .  0  0  0  0  0  0  0  0  0  0  0  0 0 None
> 0x28 24 dc  1  0  0 c  .  .  0  0  0  0  0  0  0  0  0  0  0  0 0 None
> 0x29 24 dc  1  0  0 c  .  .  0  0  0  0  0  0  0  0  0  0  0  0 0 None
> 0x2a 24 dc  1  0  0 c  .  .  0  0  0  0  0  0  0  0  0  0  0  0 0 None
(Continue reading)

Permalink | Reply | 1 comment |
headers
Matthias Hopf | 2 Mar 2009 16:42
Picon

Re: Indirect rendering to old Xservers...

On Mar 02, 09 15:28:09 +0100, Michel Dänzer wrote:
> > gkar:~ # glxinfo
> > name of display: localhost:10.0
> > Error: couldn't find RGB GLX visual
> > 
> >    visual  x  bf lv rg d st colorbuffer ax dp st accumbuffer  ms  cav
> >  id dep cl sp sz l  ci b ro  r  g  b  a bf th cl  r  g  b  a ns b eat
> > ----------------------------------------------------------------------
> > 0x23 24 tc  1  0  0 c  .  .  0  0  0  0  0  0  0  0  0  0  0  0 0 None
> > 0x24 24 tc  1  0  0 c  .  .  0  0  0  0  0  0  0  0  0  0  0  0 0 None
> > 0x25 24 tc  1  0  0 c  .  .  0  0  0  0  0  0  0  0  0  0  0  0 0 None
> > 0x26 24 tc  1  0  0 c  .  .  0  0  0  0  0  0  0  0  0  0  0  0 0 None
> > 0x27 24 dc  1  0  0 c  .  .  0  0  0  0  0  0  0  0  0  0  0  0 0 None
> > 0x28 24 dc  1  0  0 c  .  .  0  0  0  0  0  0  0  0  0  0  0  0 0 None
> > 0x29 24 dc  1  0  0 c  .  .  0  0  0  0  0  0  0  0  0  0  0  0 0 None
> > 0x2a 24 dc  1  0  0 c  .  .  0  0  0  0  0  0  0  0  0  0  0  0 0 None
> 
> This seems to work here, but the GLX visual related code was changed

You tested connecting from a recent system to a much older Xserver?

> several times recently both in xserver and mesa such that it can break
> like above if the two weren't built from snapshots from about the same
> time.

They can't be built from same versions, if client and server run on
different systems with different installations.

> I think it means libGL tries use swrast_dri.so before falling back to
> indirect rendering. This can be overridden with LIBGL_ALWAYS_INDIRECT,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian Paul | 2 Mar 2009 20:30
Favicon

Re: [PATCH] Revert change to allow DrawArrays/Elements with no vertex array enabled.

Ian Romanick wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Brian Paul wrote:
>> Eric Anholt wrote:
>>> The 2.0 spec doesn't make things extremely clear, but expresses itself in
>>> pseudocode: If the vertex array isn't enabled, then nothing is called that
>>> provokes drawing.  The manifestation of this bug was that a client drawing
>>> with no arrays enabled would get into the driver with a request to
>>> draw with _MaxElements being 0 and no inputs to the ff vertex program (since
>>> no arrays were enabled, so nothing was varying), and the driver failing
>>> all over the place.
>>>
>>> Bug #19911.
>>> ---
>>>  src/mesa/main/api_validate.c |    5 ++---
>>>  1 files changed, 2 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c
>>> index 5c8955d..5253ae3 100644
>>> --- a/src/mesa/main/api_validate.c
>>> +++ b/src/mesa/main/api_validate.c
>>>  <at>  <at>  -87,9 +87,8  <at>  <at>  check_valid_to_render(GLcontext *ctx, char *function)
>>>        return GL_FALSE;
>>>     }
>>>  
>>> -   /* Always need vertex positions, unless a vertex program is in use */
>>> -   if (!ctx->VertexProgram._Current &&
>>> -       !ctx->Array.ArrayObj->Vertex.Enabled &&
(Continue reading)

Permalink | Reply | 0 comments |

Gmane