Menu
▾
▴
mesa3d-users
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
(11) |
Apr
(46) |
May
(65) |
Jun
(85) |
Jul
(94) |
Aug
(99) |
Sep
(62) |
Oct
(58) |
Nov
(85) |
Dec
(39) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(90) |
Feb
(29) |
Mar
(90) |
Apr
(96) |
May
(78) |
Jun
(58) |
Jul
(44) |
Aug
(65) |
Sep
(40) |
Oct
(38) |
Nov
(79) |
Dec
(63) |
| 2002 |
Jan
(53) |
Feb
(61) |
Mar
(43) |
Apr
(53) |
May
(35) |
Jun
(59) |
Jul
(18) |
Aug
(12) |
Sep
(28) |
Oct
(61) |
Nov
(54) |
Dec
(23) |
| 2003 |
Jan
(16) |
Feb
(42) |
Mar
(38) |
Apr
(35) |
May
(20) |
Jun
(9) |
Jul
(10) |
Aug
(30) |
Sep
(22) |
Oct
(32) |
Nov
(25) |
Dec
(21) |
| 2004 |
Jan
(39) |
Feb
(36) |
Mar
(59) |
Apr
(32) |
May
(21) |
Jun
(4) |
Jul
(8) |
Aug
(21) |
Sep
(11) |
Oct
(21) |
Nov
(22) |
Dec
(19) |
| 2005 |
Jan
(62) |
Feb
(24) |
Mar
(17) |
Apr
(16) |
May
(16) |
Jun
(17) |
Jul
(26) |
Aug
(14) |
Sep
(13) |
Oct
(8) |
Nov
(23) |
Dec
(20) |
| 2006 |
Jan
(41) |
Feb
(18) |
Mar
(21) |
Apr
(47) |
May
(13) |
Jun
(33) |
Jul
(32) |
Aug
(21) |
Sep
(27) |
Oct
(34) |
Nov
(19) |
Dec
(46) |
| 2007 |
Jan
(21) |
Feb
(26) |
Mar
(13) |
Apr
(22) |
May
(5) |
Jun
(19) |
Jul
(56) |
Aug
(43) |
Sep
(37) |
Oct
(31) |
Nov
(53) |
Dec
(22) |
| 2008 |
Jan
(74) |
Feb
(31) |
Mar
(15) |
Apr
(35) |
May
(23) |
Jun
(26) |
Jul
(17) |
Aug
(27) |
Sep
(35) |
Oct
(30) |
Nov
(29) |
Dec
(17) |
| 2009 |
Jan
(35) |
Feb
(39) |
Mar
(44) |
Apr
(28) |
May
(20) |
Jun
(28) |
Jul
(49) |
Aug
(53) |
Sep
(23) |
Oct
(13) |
Nov
(12) |
Dec
(11) |
| 2010 |
Jan
(45) |
Feb
(28) |
Mar
(41) |
Apr
(11) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Lucas C. V. <lv...@gm...> - 2009-03-03 20:41:07
|
2009/2/27 Philipp Klaus Krause <pk...@sp...>:
> Did you compress them manually or does OpenGL compress them at
> application runtime? In the latter case you need libtxc_dxtn.
Compressed manually.
> Just try installing libtxc_dxtn (may be illegal depending on your
> jurisdiction).
>
> Philipp
Thanks for the help.
I finally came to a solution, this line in .drirc configuration file
(I would not find it without the great DRIconf application):
<option name="force_s3tc_enable" value="true" />
There is no need for libtxc_dxtn, since i945 (and all the chips I
know) have hardware accelerated DXTn compression; but it seems that if
Mesa can't find the lib, it disables the support for compression. In
my case, Ogre was decompressing it in software. The option forces Mesa
to support the compression even without software fallback (IMHO, what
should be default), and my game runs faster than ever (really, full
speed, better than Ubuntu 8.04).
It seems textures now fits in GFX memory.
One caveat though is that I was not using double buffer, so I could
see the scene being drawn, what is really bizarre. Enabling double
buffering solved this problem.
--
Lucas Clemente Vella
lv...@gm...
|
|
From: STEVE555 <ste...@ho...> - 2009-02-28 21:36:33
|
Hi to all,
I have been trying to compile the git version of mesa this past
week,but with no success.I'm using Fedora Alpha 11 Rawhide,my graphics card
is a Nvidia Geforce 6800 G.T and my monitor is a A.D.I Microscan G100 with a
B.N.C connnection.I am using both the nouveau driver and D.R.M from git.
Everytime I try and compile Mesa,I keep getting this error:
gmake[5]: Leaving directory `/tmp/mesa/src/mesa/drivers/dri/swrast'
sed -e 's,@INSTALL_DIR@,/usr,' -e 's,@INSTALL_LIB_DIR@,/usr/lib,' -e
's,@INSTALL_INC_DIR@,/usr/include,' -e 's,@VERSION@,7.3.0,' -e
's,@DRI_DRIVER_DIR@,/usr/lib/dri,' -e 's,@DRI_PC_REQ_PRIV@,libdrm >= 2.4.3,'
dri.pc.in > dri.pc
gmake[4]: Leaving directory `/tmp/mesa/src/mesa/drivers/dri'
gmake[3]: Leaving directory `/tmp/mesa/src/mesa/drivers'
gmake[2]: Leaving directory `/tmp/mesa/src/mesa'
gmake[2]: Entering directory `/tmp/mesa/src/egl'
gmake[3]: Entering directory `/tmp/mesa/src/egl/main'
Makefile:84: depend: No such file or directory
running /usr/bin/makedepend
/usr/bin/makedepend -fdepend -I/usr/lib/gcc/i586-redhat-linux/4.4.0/include
-D_GNU_SOURCE -DPTHREADS -DDEBUG -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
-I../../../include -I../../../src/mesa/glapi \
eglapi.c eglconfig.c eglconfigutil.c eglcontext.c
egldisplay.c egldriver.c eglglobals.c egllog.c eglhash.c eglmisc.c eglmode.c
eglscreen.c eglstring.c eglsurface.c eglx.c eglconfig.h eglconfigutil.h
eglcontext.h egldefines.h egldisplay.h egldriver.h eglglobals.h egllog.h
eglhash.h eglmisc.h eglmode.h eglscreen.h eglstring.h eglsurface.h eglx.h >
/dev/null 2>/dev/null
gmake[3]: Leaving directory `/tmp/mesa/src/egl/main'
gmake[3]: Entering directory `/tmp/mesa/src/egl/main'
gcc -c -I../../../include -I../../../src/mesa/glapi -g -O2 -Wall
-Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -m32 -g
-fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM
-D_GNU_SOURCE -DPTHREADS -DDEBUG -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
-D_EGL_PLATFORM_X=1 eglapi.c -o eglapi.o
gcc -c -I../../../include -I../../../src/mesa/glapi -g -O2 -Wall
-Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -m32 -g
-fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM
-D_GNU_SOURCE -DPTHREADS -DDEBUG -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
-D_EGL_PLATFORM_X=1 eglconfig.c -o eglconfig.o
gcc -c -I../../../include -I../../../src/mesa/glapi -g -O2 -Wall
-Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -m32 -g
-fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM
-D_GNU_SOURCE -DPTHREADS -DDEBUG -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
-D_EGL_PLATFORM_X=1 eglconfigutil.c -o eglconfigutil.o
eglconfigutil.c: In function ‘_eglFillInConfigs’:
eglconfigutil.c:170: warning: unused variable ‘masks_table_bgra’
eglconfigutil.c:159: warning: unused variable ‘masks_table_bgr’
gcc -c -I../../../include -I../../../src/mesa/glapi -g -O2 -Wall
-Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -m32 -g
-fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM
-D_GNU_SOURCE -DPTHREADS -DDEBUG -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
-D_EGL_PLATFORM_X=1 eglcontext.c -o eglcontext.o
gcc -c -I../../../include -I../../../src/mesa/glapi -g -O2 -Wall
-Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -m32 -g
-fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM
-D_GNU_SOURCE -DPTHREADS -DDEBUG -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
-D_EGL_PLATFORM_X=1 egldisplay.c -o egldisplay.o
gcc -c -I../../../include -I../../../src/mesa/glapi -g -O2 -Wall
-Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -m32 -g
-fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM
-D_GNU_SOURCE -DPTHREADS -DDEBUG -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
-D_EGL_PLATFORM_X=1 egldriver.c -o egldriver.o
gcc -c -I../../../include -I../../../src/mesa/glapi -g -O2 -Wall
-Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -m32 -g
-fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM
-D_GNU_SOURCE -DPTHREADS -DDEBUG -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
-D_EGL_PLATFORM_X=1 eglglobals.c -o eglglobals.o
gcc -c -I../../../include -I../../../src/mesa/glapi -g -O2 -Wall
-Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -m32 -g
-fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM
-D_GNU_SOURCE -DPTHREADS -DDEBUG -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
-D_EGL_PLATFORM_X=1 egllog.c -o egllog.o
gcc -c -I../../../include -I../../../src/mesa/glapi -g -O2 -Wall
-Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -m32 -g
-fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM
-D_GNU_SOURCE -DPTHREADS -DDEBUG -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
-D_EGL_PLATFORM_X=1 eglhash.c -o eglhash.o
gcc -c -I../../../include -I../../../src/mesa/glapi -g -O2 -Wall
-Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -m32 -g
-fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM
-D_GNU_SOURCE -DPTHREADS -DDEBUG -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
-D_EGL_PLATFORM_X=1 eglmisc.c -o eglmisc.o
gcc -c -I../../../include -I../../../src/mesa/glapi -g -O2 -Wall
-Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -m32 -g
-fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM
-D_GNU_SOURCE -DPTHREADS -DDEBUG -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
-D_EGL_PLATFORM_X=1 eglmode.c -o eglmode.o
gcc -c -I../../../include -I../../../src/mesa/glapi -g -O2 -Wall
-Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -m32 -g
-fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM
-D_GNU_SOURCE -DPTHREADS -DDEBUG -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
-D_EGL_PLATFORM_X=1 eglscreen.c -o eglscreen.o
gcc -c -I../../../include -I../../../src/mesa/glapi -g -O2 -Wall
-Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -m32 -g
-fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM
-D_GNU_SOURCE -DPTHREADS -DDEBUG -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
-D_EGL_PLATFORM_X=1 eglstring.c -o eglstring.o
gcc -c -I../../../include -I../../../src/mesa/glapi -g -O2 -Wall
-Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -m32 -g
-fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM
-D_GNU_SOURCE -DPTHREADS -DDEBUG -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
-D_EGL_PLATFORM_X=1 eglsurface.c -o eglsurface.o
gcc -c -I../../../include -I../../../src/mesa/glapi -g -O2 -Wall
-Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -m32 -g
-fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM
-D_GNU_SOURCE -DPTHREADS -DDEBUG -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
-D_EGL_PLATFORM_X=1 eglx.c -o eglx.o
/bin/sh ../../../bin/mklib -o EGL -linker 'gcc' -ldflags '' \
-major 1 -minor 0 \
-install ../../../lib \
@EGL_LIB_DEPS@ 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 Linux shared library: libEGL.so.1.0
gcc: @EGL_LIB_DEPS@: No such file or directory
mklib: Installing libEGL.so.1.0 libEGL.so.1 libEGL.so in ../../../lib
mv: cannot stat `libEGL.so.1.0': No such file or directory
gmake[3]: *** [../../../lib/libEGL.so] Error 1
gmake[3]: Leaving directory `/tmp/mesa/src/egl/main'
gmake[2]: *** [subdirs] Error 1
gmake[2]: Leaving directory `/tmp/mesa/src/egl'
gmake[1]: *** [subdirs] Error 1
gmake[1]: Leaving directory `/tmp/mesa/src'
gmake: *** [default] Error 1
You have new mail in /var/spool/mail/root
[root@x1-6-00-c9-00-02-c6-36 mesa]#
I've used locate libEGL.so and it is definetley in /usr/lib.I use autoconf
to compile with these options:
./configure --prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
--libdir=/usr/lib --includedir=/usr/include --build=i686-pc-linux-gnu
--host=i686-pc-linux-gnu --enable-gallium-nouveau --enable-32-bit
--enable-xcb --enable-glx-tls --enable-motif --with-x
--enable-debug --with-expat=/lib
I had a go building with scons.I did build it ok,but I don't think it built
the nouveau_dri.so,only the Intel915,and I wasn't sure howe to install using
scons after it was built.
I think my build problems started with a recent commit,which was:autoconf:
Fixup EGL build I'm not really sure if it is related to my problem.
I hope somebody can help me with this one,
Regards,
STEVE555
--
View this message in context: http://www.nabble.com/EGL-error-tp22267122p22267122.html
Sent from the mesa3d-users mailing list archive at Nabble.com.
|
|
From: Philipp K. K. <pk...@sp...> - 2009-02-27 23:02:55
|
Lucas Clemente Vella schrieb: > So, I figured out that the true level runs at the same speed it ran in > the old system when my textures were not compressed. Back then, when I > compressed the textures with DXT1, the game started to run at not so > bad 10 FPS. Did you compress them manually or does OpenGL compress them at application runtime? In the latter case you need libtxc_dxtn. > > [...] > > Also, running a debug version of Mesa (Ubuntu sources, just compiled > again), I get this message: > Mesa warning: couldn't open libtxc_dxtn.so, software DXTn > compression/decompression unavailable > Is it somehow affecting me? > Just try installing libtxc_dxtn (may be illegal depending on your jurisdiction). Philipp |
|
From: Lucas C. V. <lv...@gm...> - 2009-02-25 20:22:42
|
2009/2/20 Lucas Clemente Vella <lv...@gm...>: > I still have no success finding the why of the slowdown. While I don't > know how to properly use oprofile, this is the best info I could get > from it: > > 72.02% of the time is spent inside glibc, on memcpy > > depending on opreport paremeters, on the same profiling, I also get: > > samples % linenr info image name > symbol name > 449 87.1845 (no location information) [vdso] (tgid:18705 > range:0xb804d000-0xb804e000) (no symbols) > > Does all this memcopying means something to you? I found that with low memory consuming scenes, I have about the same speed I used to have. In my test level I have no textures, a few vertex buffers and hundreds of polygons. The game runs at capped 30 FPS with 17% processor consuming. In the true level, I have many textures, many vertex buffers -- both managed by Ogre -- and (trusting in the scene culling) about the same number of polygons. The game runs at about 1 FPS, consuming 100% of processor time. So, I figured out that the true level runs at the same speed it ran in the old system when my textures were not compressed. Back then, when I compressed the textures with DXT1, the game started to run at not so bad 10 FPS. Now it is slow again. Judging by the profiler info, I guess the system update somehow screwed my shared memory size so memcpy's form main memory are needed. Does it make sense? Can I get the old behavior? Also, running a debug version of Mesa (Ubuntu sources, just compiled again), I get this message: Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable Is it somehow affecting me? -- Lucas Clemente Vella lv...@gm... |
|
From: Jerome G. <gl...@fr...> - 2009-02-25 12:44:57
|
On Wed, 2009-02-25 at 14:20 +0800, zhou jiangwei wrote: > hi, > i am a newer to DRI. can someone give me a description about : > how to render one 2D window to one 3D window space in DRI mode? > > > i guess, the 2D window will be renered to 3D window as texture, is > it right? > > hope to get detailed description about this process. > > thanks > It's up to the toolkit you use to allow you to render to a texture and then up to you to create a GL texture out of it. AFAIK this is still WIP in GTK or in QT. If you are referring to what compiz or others compositor achieve then it's a whole different issue and this feature is only given to the window manager. Cheers, Jerome Glisse |
|
From: zhou j. <nj...@ho...> - 2009-02-25 06:20:48
|
hi, i am a newer to DRI. can someone give me a description about : how to render one 2D window to one 3D window space in DRI mode? i guess, the 2D window will be renered to 3D window as texture, is it right? hope to get detailed description about this process. thanks _________________________________________________________________ Drag n’ drop—Get easy photo sharing with Windows Live™ Photos. http://www.microsoft.com/windows/windowslive/products/photos.aspx |
|
From: zhengjun <jun...@sa...> - 2009-02-24 06:38:09
|
Firstly, thank you for your reply. The FB here means a fbdev or some API to operate it. No window system or event arch is supposed to be included in it. EGL or DRM are good ideas for it, but we have no time to do the porting work , so I wanna use some existing architecture. Thanks again Zheng Jun ------- Original Message ------- Sender : Jerome Glisse<gl...@fr...> Date : 二月 23, 2009 20:50 (GMT+09:00) Title : Re: [Mesa3d-users] Implement OpenGL and FB on x86 without X On Mon, 2009-02-23 at 10:00 +0000, zhengjun wrote: > Hi, folks > > I'm trying to implement OpenGL and FB interface on an x86 PC. > The hw acceleration should be used for the Gfx card. And we don't > want to use X. So I think the Mesa on DRI will be fine for the OpenGL > interface. And when considering of FB operation, I'm a little confused. > AFAIK, it seems that there are 2 way to integrate the FB and Mesa: > 1. use the glDrawPixels/CopyPixels functions > 2. use glRenderBufferEXT functions > > I've told that the first way is low efficient, and the second way can not > be implemented without X. > > Is there anyway else, or have I miss anything ? > > TIA > > Zheng Jun What you mean by FB ? The kernel FB interface ? If so i would suggest that you consider kernel modesetting inside drm, this is where we want to go and with it you can achieve hw accel of GL without X for instance look at wayland http://hoegsberg.blogspot.com/ It uses hw accel through GL without X (the demonstration shows X running inside wayland but X is not involved in wayland accelerated rendering). Most of these is based on EGL one implementation is at: git://people.freedesktop.org/~krh/eagle Although i believe the plan is to add EGL to mesa (it's already there but i think it's not working right now). Cheers, Jerome Glisse |
|
From: Sam E. <em...@ya...> - 2009-02-23 20:31:45
|
Thanks so much for your suggestions Tom. I was only trying out Mesa/OSMesa in a very quick test last week (exploring various rendering solutions), so don't know yet if we'll really be working with it. tom fogal-3 wrote: > > [snip] > First, though, I recommend you build MesaOpenGL32.dll when > USE_MGL_NAMESPACE is defined. This will allow you to link both OpenGL > and mangled Mesa in the same program. > > I only care about this on Linux, but it would be a neat feature-bullet > if it worked on Windows (and Mac, for that matter). If you would be > interested in collaborating, please contact me off-list. > > Best, > > -tom > > [1] Sort of. I only care about one context per process, but I don't > know which until I've gone through some runtime initialization. > >> Karl Schultz wrote: >> > >> > You probably have to change _glapi_get_context to _mglapi_get_context >> > in mesa.def. I guess the leading '_' was to blame. >> > >> > Here's how to solve the problem on your own: >> > >> > You're in VS8, right? >> > >> > Use "Find in Files" to find all occurrences of "glapi_get_context". >> > >> > It shows up in mesa.def. good >> > >> > In glapi.h, we see: >> > >> > #if defined(USE_MGL_NAMESPACE) >> > #define _glapi_set_dispatch _mglapi_set_dispatch >> > #define _glapi_get_dispatch _mglapi_get_dispatch >> > #define _glapi_set_context _mglapi_set_context >> > #define _glapi_get_context _mglapi_get_context >> > #define _glapi_Context _mglapi_Context >> > #define _glapi_Dispatch _mglapi_Dispatch >> > #endif >> > >> > Ah, it does get mangled, so the def file needs to export the mangled >> > symbol. >> > >> > Karl >> > >> > >> > On Thu, Feb 19, 2009 at 2:17 PM, Sam Eml <em...@ya...> wrote: >> >> >> >> Hi, >> >> >> >> I'm trying to build Mesa with mangled namespace in VC8 as described in >> >> the >> >> README.WIN32: I've specified the preprocessor flag USE_MGL_NAMESPACE >> in >> >> the >> >> project settings, and changed the gl* symbols to mgl* in mesa.def >> >> (drivers/windows/gdi/mesa.def). >> >> >> >> The mesa project of the solution builds ok, but the gdi project gives: >> >> >> >> error LNK2001: unresolved external symbol _glapi_get_context >> mesa.def >> >> fatal error LNK1120: 1 unresolved externals >> >> ...\Mesa-7.3\windows\VC8\mesa\Debug\OPENGL32.lib >> >> >> >> Would anyone have any ideas? >> >> >> >> -- >> >> View this message in context: >> >> >> http://www.nabble.com/link-error-with-USE_MGL_NAMESPACE-tp22109892p2210989 >> 2.html >> >> Sent from the mesa3d-users mailing list archive at Nabble.com. >> >> >> >> >> >> >> -------------------------------------------------------------------------- >> ---- >> >> 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 >> >> _______________________________________________ >> >> Mesa3d-users mailing list >> >> Mes...@li... >> >> https://lists.sourceforge.net/lists/listinfo/mesa3d-users >> >> >> > >> > >> --------------------------------------------------------------------------- >> --- >> > 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 >> > _______________________________________________ >> > Mesa3d-users mailing list >> > Mes...@li... >> > https://lists.sourceforge.net/lists/listinfo/mesa3d-users >> > >> > >> >> -- >> View this message in context: >> http://www.nabble.com/link-error-with-USE_MGL_N >> AMESPACE-tp22109892p22166971.html >> Sent from the mesa3d-users mailing list archive at Nabble.com. >> >> >> ----------------------------------------------------------------------------- >> - >> 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 >> _______________________________________________ >> Mesa3d-users mailing list >> Mes...@li... >> https://lists.sourceforge.net/lists/listinfo/mesa3d-users > > ------------------------------------------------------------------------------ > 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 > _______________________________________________ > Mesa3d-users mailing list > Mes...@li... > https://lists.sourceforge.net/lists/listinfo/mesa3d-users > > -- View this message in context: http://www.nabble.com/link-error-with-USE_MGL_NAMESPACE-tp22109892p22169488.html Sent from the mesa3d-users mailing list archive at Nabble.com. |
|
From: tom f. <tf...@al...> - 2009-02-23 19:31:43
|
Sam Eml <em...@ya...> writes:
[snip]
> so perhaps I just needed to include glprocs.h somewhere rather than change
> wmesa.c. Anyway, I managed to build opengl32.dll and osmesa32.dll with
> USE_MGL_NAMESPACE defined, but am still not sure how to use both this Mesa
> opengl32.dll and the default opengl32.dll at the same time at runtime (eg.
> call mgl*() functions in one context and gl*() functions in another).
I am currently working on getting exactly this [1] to work in GLEW, so
I would recommend going down that route.
First, though, I recommend you build MesaOpenGL32.dll when
USE_MGL_NAMESPACE is defined. This will allow you to link both OpenGL
and mangled Mesa in the same program.
I only care about this on Linux, but it would be a neat feature-bullet
if it worked on Windows (and Mac, for that matter). If you would be
interested in collaborating, please contact me off-list.
Best,
-tom
[1] Sort of. I only care about one context per process, but I don't
know which until I've gone through some runtime initialization.
> Karl Schultz wrote:
> >
> > You probably have to change _glapi_get_context to _mglapi_get_context
> > in mesa.def. I guess the leading '_' was to blame.
> >
> > Here's how to solve the problem on your own:
> >
> > You're in VS8, right?
> >
> > Use "Find in Files" to find all occurrences of "glapi_get_context".
> >
> > It shows up in mesa.def. good
> >
> > In glapi.h, we see:
> >
> > #if defined(USE_MGL_NAMESPACE)
> > #define _glapi_set_dispatch _mglapi_set_dispatch
> > #define _glapi_get_dispatch _mglapi_get_dispatch
> > #define _glapi_set_context _mglapi_set_context
> > #define _glapi_get_context _mglapi_get_context
> > #define _glapi_Context _mglapi_Context
> > #define _glapi_Dispatch _mglapi_Dispatch
> > #endif
> >
> > Ah, it does get mangled, so the def file needs to export the mangled
> > symbol.
> >
> > Karl
> >
> >
> > On Thu, Feb 19, 2009 at 2:17 PM, Sam Eml <em...@ya...> wrote:
> >>
> >> Hi,
> >>
> >> I'm trying to build Mesa with mangled namespace in VC8 as described in
> >> the
> >> README.WIN32: I've specified the preprocessor flag USE_MGL_NAMESPACE in
> >> the
> >> project settings, and changed the gl* symbols to mgl* in mesa.def
> >> (drivers/windows/gdi/mesa.def).
> >>
> >> The mesa project of the solution builds ok, but the gdi project gives:
> >>
> >> error LNK2001: unresolved external symbol _glapi_get_context mesa.def
> >> fatal error LNK1120: 1 unresolved externals
> >> ...\Mesa-7.3\windows\VC8\mesa\Debug\OPENGL32.lib
> >>
> >> Would anyone have any ideas?
> >>
> >> --
> >> View this message in context:
> >> http://www.nabble.com/link-error-with-USE_MGL_NAMESPACE-tp22109892p2210989
> 2.html
> >> Sent from the mesa3d-users mailing list archive at Nabble.com.
> >>
> >>
> >> --------------------------------------------------------------------------
> ----
> >> 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
> >> _______________________________________________
> >> Mesa3d-users mailing list
> >> Mes...@li...
> >> https://lists.sourceforge.net/lists/listinfo/mesa3d-users
> >>
> >
> > ---------------------------------------------------------------------------
> ---
> > 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
> > _______________________________________________
> > Mesa3d-users mailing list
> > Mes...@li...
> > https://lists.sourceforge.net/lists/listinfo/mesa3d-users
> >
> >
>
> --
> View this message in context: http://www.nabble.com/link-error-with-USE_MGL_N
> AMESPACE-tp22109892p22166971.html
> Sent from the mesa3d-users mailing list archive at Nabble.com.
>
>
> -----------------------------------------------------------------------------
> -
> 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
> _______________________________________________
> Mesa3d-users mailing list
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa3d-users
|
|
From: Sam E. <em...@ya...> - 2009-02-23 18:16:01
|
Thanks for your help Karl. Besides adding _mglapi_get_context to mesa.def, I found that I also had to rename gl_dispatch_stub_*() to mgl_dispatch_stub_*() in wmesa.c and rename glu* to mglu* in glu.def ... I later noticed that glprocs.h has: #ifdef USE_MGL_NAMESPACE #define gl_dispatch_stub_343 mgl_dispatch_stub_343 #define gl_dispatch_stub_344 mgl_dispatch_stub_344 ... so perhaps I just needed to include glprocs.h somewhere rather than change wmesa.c. Anyway, I managed to build opengl32.dll and osmesa32.dll with USE_MGL_NAMESPACE defined, but am still not sure how to use both this Mesa opengl32.dll and the default opengl32.dll at the same time at runtime (eg. call mgl*() functions in one context and gl*() functions in another). Karl Schultz wrote: > > You probably have to change _glapi_get_context to _mglapi_get_context > in mesa.def. I guess the leading '_' was to blame. > > Here's how to solve the problem on your own: > > You're in VS8, right? > > Use "Find in Files" to find all occurrences of "glapi_get_context". > > It shows up in mesa.def. good > > In glapi.h, we see: > > #if defined(USE_MGL_NAMESPACE) > #define _glapi_set_dispatch _mglapi_set_dispatch > #define _glapi_get_dispatch _mglapi_get_dispatch > #define _glapi_set_context _mglapi_set_context > #define _glapi_get_context _mglapi_get_context > #define _glapi_Context _mglapi_Context > #define _glapi_Dispatch _mglapi_Dispatch > #endif > > Ah, it does get mangled, so the def file needs to export the mangled > symbol. > > Karl > > > On Thu, Feb 19, 2009 at 2:17 PM, Sam Eml <em...@ya...> wrote: >> >> Hi, >> >> I'm trying to build Mesa with mangled namespace in VC8 as described in >> the >> README.WIN32: I've specified the preprocessor flag USE_MGL_NAMESPACE in >> the >> project settings, and changed the gl* symbols to mgl* in mesa.def >> (drivers/windows/gdi/mesa.def). >> >> The mesa project of the solution builds ok, but the gdi project gives: >> >> error LNK2001: unresolved external symbol _glapi_get_context mesa.def >> fatal error LNK1120: 1 unresolved externals >> ...\Mesa-7.3\windows\VC8\mesa\Debug\OPENGL32.lib >> >> Would anyone have any ideas? >> >> -- >> View this message in context: >> http://www.nabble.com/link-error-with-USE_MGL_NAMESPACE-tp22109892p22109892.html >> Sent from the mesa3d-users mailing list archive at Nabble.com. >> >> >> ------------------------------------------------------------------------------ >> 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 >> _______________________________________________ >> Mesa3d-users mailing list >> Mes...@li... >> https://lists.sourceforge.net/lists/listinfo/mesa3d-users >> > > ------------------------------------------------------------------------------ > 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 > _______________________________________________ > Mesa3d-users mailing list > Mes...@li... > https://lists.sourceforge.net/lists/listinfo/mesa3d-users > > -- View this message in context: http://www.nabble.com/link-error-with-USE_MGL_NAMESPACE-tp22109892p22166971.html Sent from the mesa3d-users mailing list archive at Nabble.com. |
|
From: Jerome G. <gl...@fr...> - 2009-02-23 12:09:27
|
On Mon, 2009-02-23 at 10:00 +0000, zhengjun wrote: > Hi, folks > > I'm trying to implement OpenGL and FB interface on an x86 PC. > The hw acceleration should be used for the Gfx card. And we don't > want to use X. So I think the Mesa on DRI will be fine for the OpenGL > interface. And when considering of FB operation, I'm a little confused. > AFAIK, it seems that there are 2 way to integrate the FB and Mesa: > 1. use the glDrawPixels/CopyPixels functions > 2. use glRenderBufferEXT functions > > I've told that the first way is low efficient, and the second way can not > be implemented without X. > > Is there anyway else, or have I miss anything ? > > TIA > > Zheng Jun What you mean by FB ? The kernel FB interface ? If so i would suggest that you consider kernel modesetting inside drm, this is where we want to go and with it you can achieve hw accel of GL without X for instance look at wayland http://hoegsberg.blogspot.com/ It uses hw accel through GL without X (the demonstration shows X running inside wayland but X is not involved in wayland accelerated rendering). Most of these is based on EGL one implementation is at: git://people.freedesktop.org/~krh/eagle Although i believe the plan is to add EGL to mesa (it's already there but i think it's not working right now). Cheers, Jerome Glisse |
|
From: zhengjun <jun...@sa...> - 2009-02-23 10:00:42
|
Hi, folks I'm trying to implement OpenGL and FB interface on an x86 PC. The hw acceleration should be used for the Gfx card. And we don't want to use X. So I think the Mesa on DRI will be fine for the OpenGL interface. And when considering of FB operation, I'm a little confused. AFAIK, it seems that there are 2 way to integrate the FB and Mesa: 1. use the glDrawPixels/CopyPixels functions 2. use glRenderBufferEXT functions I've told that the first way is low efficient, and the second way can not be implemented without X. Is there anyway else, or have I miss anything ? TIA Zheng Jun |
|
From: jun z. <jun...@sa...> - 2009-02-23 09:57:23
|
Hi, folks I'm trying to implement OpenGL and FB interface on an x86 PC. The hw acceleration should be used for the Gfx card. And we don't want to use X. So I think the Mesa on DRI will be fine for the OpenGL interface. And when considering of FB operation, I'm a little confused. AFAIK, it seems that there are 2 way to integrate the FB and Mesa: 1. use the glDrawPixels/CopyPixels functions 2. use glRenderBufferEXT functions I've told that the first way is low efficient, and the second way can not be implemented without X. Is there anyway else, or have I miss anything ? TIA Zheng Jun |
|
From: STEVE555 <ste...@ho...> - 2009-02-21 18:26:08
|
Hi to all,
I think I have fixed the error with i965 being called by
configure,I simply deleted the reference to i965 on line
9273.
The i965 driver still gets built when I rum gmake,but I'm glad it runs past
that error.
The trouble is gmake stops with this new error,and I'm not sure how to solve
this one:
gmake[4]: Leaving directory `/tmp/mesa/src/gallium/drivers/i915simple'
gmake[4]: Entering directory `/tmp/mesa/src/gallium/drivers/nv04'
rm -f depend
touch depend
/usr/bin/makedepend -fdepend -I/usr/lib/gcc/i586-redhat-linux/4.4.0/include
-I. -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary
-I../../../../src/gallium/drivers -I/src/gallium/include
-I/src/gallium/auxiliary -I/src/gallium/drivers nv04_surface_2d.c
nv04_clear.c nv04_context.c nv04_fragprog.c nv04_fragtex.c nv04_miptree.c
nv04_prim_vbuf.c nv04_screen.c nv04_state.c nv04_state_emit.c nv04_surface.c
nv04_vbo.c 2> /dev/null
gmake[4]: Leaving directory `/tmp/mesa/src/gallium/drivers/nv04'
gmake[4]: Entering directory `/tmp/mesa/src/gallium/drivers/nv04'
gcc -c -I. -I../../../../src/gallium/include
-I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers
-I/src/gallium/include -I/src/gallium/auxiliary -I/src/gallium/drivers -g
-O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing
-m32 -g -fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM
-D_GNU_SOURCE -DPTHREADS -DDEBUG -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
nv04_surface_2d.c -o nv04_surface_2d.o
nv04_surface_2d.c: In function ‘nv04_surface_copy_swizzle’:
nv04_surface_2d.c:133: error: ‘struct pipe_surface’ has no member named
‘block’
nv04_surface_2d.c:149: error: ‘struct pipe_surface’ has no member named
‘stride’
nv04_surface_2d.c:152: error: ‘struct pipe_surface’ has no member named
‘stride’
nv04_surface_2d.c:153: error: ‘struct pipe_surface’ has no member named
‘block’
nv04_surface_2d.c: In function ‘nv04_surface_copy_m2mf’:
nv04_surface_2d.c:173: error: ‘struct pipe_surface’ has no member named
‘stride’
nv04_surface_2d.c:173: error: ‘struct pipe_surface’ has no member named
‘block’
nv04_surface_2d.c:174: error: ‘struct pipe_surface’ has no member named
‘stride’
nv04_surface_2d.c:174: error: ‘struct pipe_surface’ has no member named
‘block’
nv04_surface_2d.c:191: error: ‘struct pipe_surface’ has no member named
‘stride’
nv04_surface_2d.c:192: error: ‘struct pipe_surface’ has no member named
‘stride’
nv04_surface_2d.c:193: error: ‘struct pipe_surface’ has no member named
‘block’
nv04_surface_2d.c:199: error: ‘struct pipe_surface’ has no member named
‘stride’
nv04_surface_2d.c:200: error: ‘struct pipe_surface’ has no member named
‘stride’
nv04_surface_2d.c: In function ‘nv04_surface_copy_blit’:
nv04_surface_2d.c:228: error: ‘struct pipe_surface’ has no member named
‘stride’
nv04_surface_2d.c:228: error: ‘struct pipe_surface’ has no member named
‘stride’
nv04_surface_2d.c: In function ‘nv04_surface_copy’:
nv04_surface_2d.c:260: error: ‘struct pipe_surface’ has no member named
‘stride’
nv04_surface_2d.c:260: error: ‘struct pipe_surface’ has no member named
‘stride’
nv04_surface_2d.c: In function ‘nv04_surface_fill’:
nv04_surface_2d.c:290: error: ‘struct pipe_surface’ has no member named
‘stride’
nv04_surface_2d.c:290: error: ‘struct pipe_surface’ has no member named
‘stride’
gmake[4]: *** [nv04_surface_2d.o] Error 1
gmake[4]: Leaving directory `/tmp/mesa/src/gallium/drivers/nv04'
gmake[3]: *** [default] Error 1
gmake[3]: Leaving directory `/tmp/mesa/src/gallium/drivers'
gmake[2]: *** [default] Error 1
gmake[2]: Leaving directory `/tmp/mesa/src/gallium'
gmake[1]: *** [subdirs] Error 1
gmake[1]: Leaving directory `/tmp/mesa/src'
gmake: *** [default] Error 1
I hope somebody would be able to help me with this one.
Regards,
STEVE555
--
View this message in context: http://www.nabble.com/Compiling-problems-with-MESA-from-Git-tp22111678p22138687.html
Sent from the mesa3d-users mailing list archive at Nabble.com.
|
|
From: Karl S. <kar...@gm...> - 2009-02-21 15:37:18
|
You probably have to change _glapi_get_context to _mglapi_get_context in mesa.def. I guess the leading '_' was to blame. Here's how to solve the problem on your own: You're in VS8, right? Use "Find in Files" to find all occurrences of "glapi_get_context". It shows up in mesa.def. good In glapi.h, we see: #if defined(USE_MGL_NAMESPACE) #define _glapi_set_dispatch _mglapi_set_dispatch #define _glapi_get_dispatch _mglapi_get_dispatch #define _glapi_set_context _mglapi_set_context #define _glapi_get_context _mglapi_get_context #define _glapi_Context _mglapi_Context #define _glapi_Dispatch _mglapi_Dispatch #endif Ah, it does get mangled, so the def file needs to export the mangled symbol. Karl On Thu, Feb 19, 2009 at 2:17 PM, Sam Eml <em...@ya...> wrote: > > Hi, > > I'm trying to build Mesa with mangled namespace in VC8 as described in the > README.WIN32: I've specified the preprocessor flag USE_MGL_NAMESPACE in the > project settings, and changed the gl* symbols to mgl* in mesa.def > (drivers/windows/gdi/mesa.def). > > The mesa project of the solution builds ok, but the gdi project gives: > > error LNK2001: unresolved external symbol _glapi_get_context mesa.def > fatal error LNK1120: 1 unresolved externals > ...\Mesa-7.3\windows\VC8\mesa\Debug\OPENGL32.lib > > Would anyone have any ideas? > > -- > View this message in context: http://www.nabble.com/link-error-with-USE_MGL_NAMESPACE-tp22109892p22109892.html > Sent from the mesa3d-users mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > 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 > _______________________________________________ > Mesa3d-users mailing list > Mes...@li... > https://lists.sourceforge.net/lists/listinfo/mesa3d-users > |
|
From: Lucas C. V. <lv...@gm...> - 2009-02-20 20:02:02
|
I still have no success finding the why of the slowdown. While I don't know how to properly use oprofile, this is the best info I could get from it: 72.02% of the time is spent inside glibc, on memcpy depending on opreport paremeters, on the same profiling, I also get: samples % linenr info image name symbol name 449 87.1845 (no location information) [vdso] (tgid:18705 range:0xb804d000-0xb804e000) (no symbols) Does all this memcopying means something to you? -- Lucas Clemente Vella lv...@gm... |
|
From: Brian P. <br...@vm...> - 2009-02-20 16:51:36
|
Lucas Clemente Vella wrote: > Brian Paul escreveu: >> You've got a 965 chipset but Lucas has 945. >> >> The 945 hardware does not support loops/conditionals/etc which are >> needed for fragment shaders. The best we could do is to switch between >> hardware and software rendering depending on what features the shaders use. >> >> In general, people don't like it when performance goes off a cliff when >> a software fallback is hit. That's why GLSL is not exposed on 945. >> >> -Brian > > But if the CG compiler could generate the programs for it, then the GLSL > should be able, too. > > I am not sure what magic it is done inside the CG compiler to handle > 'if', but the vertex shader had one, and worked on i945. > . if-statements can sometimes be converted into compare/selection statements. See the ARB_f_p CMP instruction, for example. Mesa's GLSL compiler doesn't do that transformation though. -Brian |
|
From: Brian P. <br...@vm...> - 2009-02-20 16:42:19
|
STEVE555 wrote: > Hi Paul, > I'm pretty sure I'm getting the latest code from git.The clone > address I use is: > git clone git://anongit.freedesktop.org/git/mesa/mesa I always use git pull > origin to get the latest updates from the repository,along with the > repositories for DRM and xf86-video-nouveau.I use Konsole as my main > terminal. > > I always use gmake -B realclean to be sure the code is as clean as possilbe > before I do a fresh compile. > > Here is the output when I start configure with the options I posted in my > first post: [...] The gallium 965 driver should not be built since it's way out of date. I'm not sure where the "gallium drivers dirs" list is specified with autoconf (I usually don't use autoconf) but i965simple should not be in the list. Maybe you can figure that out and submit a patch. -Brian |
|
From: STEVE555 <ste...@ho...> - 2009-02-20 16:35:40
|
STEVE555 wrote: > > Hi Paul, > I'm pretty sure I'm getting the latest code from git.The clone > address I use is: > git clone git://anongit.freedesktop.org/git/mesa/mesa I always use git > pull origin to get the latest updates from the repository,along with the > repositories for DRM and xf86-video-nouveau.I use Konsole as my main > terminal. > > I always use gmake -B realclean to be sure the code is as clean as > possilbe before I do a fresh compile. > > Here is the output when I start configure with the options I posted in my > first post: > > [root@localhost mesa]# ./configure --prefix=/usr --bindir=/usr/bin > --sbindir=/usr/sbin --libdir=/usr/lib --includedir=/usr/include > --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu > --enable-gallium-nouveau --enable-32-bit --enable-xcb --enable-glx-tls > --enable-motif --enable-debug --with-x > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking for i686-pc-linux-gnu-gcc... no > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ISO C89... none needed > checking how to run the C preprocessor... gcc -E > checking for i686-pc-linux-gnu-gcc... gcc > checking whether we are using the GNU C compiler... (cached) yes > checking whether gcc accepts -g... (cached) yes > checking for gcc option to accept ISO C89... (cached) none needed > checking for i686-pc-linux-gnu-g++... no > checking for i686-pc-linux-gnu-c++... no > checking for i686-pc-linux-gnu-gpp... no > checking for i686-pc-linux-gnu-aCC... no > checking for i686-pc-linux-gnu-CC... no > checking for i686-pc-linux-gnu-cxx... no > checking for i686-pc-linux-gnu-cc++... no > checking for i686-pc-linux-gnu-cl.exe... no > checking for i686-pc-linux-gnu-FCC... no > checking for i686-pc-linux-gnu-KCC... no > checking for i686-pc-linux-gnu-RCC... no > checking for i686-pc-linux-gnu-xlC_r... no > checking for i686-pc-linux-gnu-xlC... no > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking for gmake... gmake > checking for makedepend... /usr/bin/makedepend > checking for sed... /bin/sed > checking for i686-pc-linux-gnu-pkg-config... no > checking for pkg-config... /usr/bin/pkg-config > checking pkg-config is at least version 0.9.0... yes > checking whether to enable assembly... yes, x86 > checking for gcc option to produce PIC... -fPIC > checking for dlopen... no > checking for dlopen in -ldl... yes > checking for posix_memalign... yes > checking pkg-config files for X11 are available... yes > checking for LIBDRM... yes > checking for DRI2PROTO... yes > checking for DRIGL... yes > checking expat.h usability... yes > checking expat.h presence... yes > checking for expat.h... yes > checking for XML_ParserCreate in -lexpat... yes > checking for GLW... yes > checking for motif-config... /usr/bin/motif-config > checking for GLUT... yes > configure: creating ./config.status > config.status: creating configs/autoconf > config.status: executing configs commands > > prefix: /usr > exec_prefix: ${prefix} > libdir: /usr/lib > includedir: /usr/include > > Driver: dri > OSMesa: no > DRI drivers: i810 i915 i965 mach64 mga r128 r200 r300 radeon > s3v savage sis tdfx trident unichrome ffb swrast > DRI driver dir: ${libdir}/dri > Use XCB: yes > > Gallium: yes > Gallium dirs: auxiliary drivers state_trackers > Winsys dirs: drm > Winsys drm dirs: intel nouveau > Auxiliary dirs: draw translate cso_cache pipebuffer tgsi sct > rtasm util > Driver dirs: softpipe failover trace i915simple i965simple > nv04 nv10 nv20 nv30 nv40 nv50 > Trackers dirs: egl > > Shared libs: yes > Static libs: no > GLU: yes > GLw: yes (Motif: yes) > glut: yes > Demos: xdemos demos redbook samples glsl > > CFLAGS: -g -O2 -Wall -Wmissing-prototypes -std=c99 > -ffast-math -fno-strict-aliasing -m32 -g -fPIC > CXXFLAGS: -g -O2 -Wall -fno-strict-aliasing -m32 -g -fPIC > Macros: -D_GNU_SOURCE -DPTHREADS -DDEBUG > -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 -DUSE_X86_ASM -DUSE_MMX_ASM > -DUSE_3DNOW_ASM -DUSE_SSE_ASM > > Run 'gmake' to build Mesa > > I'll post a new reply if it has been successful or not. > > Regards, > STEVE555 > *update* I've just got the latest updates from the repository today,but sadly it failed to build,but with a different error this time.I can wait for a few hours to see if there are any more commits to the repository. I'm going to attach a text file of the build process to where it failed to anybody who is interested. -- View this message in context: http://www.nabble.com/Compiling-problems-with-MESA-from-Git-tp22111678p22121146.html Sent from the mesa3d-users mailing list archive at Nabble.com. |
|
From: STEVE555 <ste...@ho...> - 2009-02-20 16:04:38
|
Hi Paul,
I'm pretty sure I'm getting the latest code from git.The clone
address I use is:
git clone git://anongit.freedesktop.org/git/mesa/mesa I always use git pull
origin to get the latest updates from the repository,along with the
repositories for DRM and xf86-video-nouveau.I use Konsole as my main
terminal.
I always use gmake -B realclean to be sure the code is as clean as possilbe
before I do a fresh compile.
Here is the output when I start configure with the options I posted in my
first post:
[root@localhost mesa]# ./configure --prefix=/usr --bindir=/usr/bin
--sbindir=/usr/sbin --libdir=/usr/lib --includedir=/usr/include
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --enable-gallium-nouveau
--enable-32-bit --enable-xcb --enable-glx-tls --enable-motif --enable-debug
--with-x
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking for i686-pc-linux-gnu-gcc... no
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... gcc -E
checking for i686-pc-linux-gnu-gcc... gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking for i686-pc-linux-gnu-g++... no
checking for i686-pc-linux-gnu-c++... no
checking for i686-pc-linux-gnu-gpp... no
checking for i686-pc-linux-gnu-aCC... no
checking for i686-pc-linux-gnu-CC... no
checking for i686-pc-linux-gnu-cxx... no
checking for i686-pc-linux-gnu-cc++... no
checking for i686-pc-linux-gnu-cl.exe... no
checking for i686-pc-linux-gnu-FCC... no
checking for i686-pc-linux-gnu-KCC... no
checking for i686-pc-linux-gnu-RCC... no
checking for i686-pc-linux-gnu-xlC_r... no
checking for i686-pc-linux-gnu-xlC... no
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for gmake... gmake
checking for makedepend... /usr/bin/makedepend
checking for sed... /bin/sed
checking for i686-pc-linux-gnu-pkg-config... no
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking whether to enable assembly... yes, x86
checking for gcc option to produce PIC... -fPIC
checking for dlopen... no
checking for dlopen in -ldl... yes
checking for posix_memalign... yes
checking pkg-config files for X11 are available... yes
checking for LIBDRM... yes
checking for DRI2PROTO... yes
checking for DRIGL... yes
checking expat.h usability... yes
checking expat.h presence... yes
checking for expat.h... yes
checking for XML_ParserCreate in -lexpat... yes
checking for GLW... yes
checking for motif-config... /usr/bin/motif-config
checking for GLUT... yes
configure: creating ./config.status
config.status: creating configs/autoconf
config.status: executing configs commands
prefix: /usr
exec_prefix: ${prefix}
libdir: /usr/lib
includedir: /usr/include
Driver: dri
OSMesa: no
DRI drivers: i810 i915 i965 mach64 mga r128 r200 r300 radeon s3v
savage sis tdfx trident unichrome ffb swrast
DRI driver dir: ${libdir}/dri
Use XCB: yes
Gallium: yes
Gallium dirs: auxiliary drivers state_trackers
Winsys dirs: drm
Winsys drm dirs: intel nouveau
Auxiliary dirs: draw translate cso_cache pipebuffer tgsi sct rtasm
util
Driver dirs: softpipe failover trace i915simple i965simple nv04
nv10 nv20 nv30 nv40 nv50
Trackers dirs: egl
Shared libs: yes
Static libs: no
GLU: yes
GLw: yes (Motif: yes)
glut: yes
Demos: xdemos demos redbook samples glsl
CFLAGS: -g -O2 -Wall -Wmissing-prototypes -std=c99
-ffast-math -fno-strict-aliasing -m32 -g -fPIC
CXXFLAGS: -g -O2 -Wall -fno-strict-aliasing -m32 -g -fPIC
Macros: -D_GNU_SOURCE -DPTHREADS -DDEBUG
-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 -DUSE_X86_ASM -DUSE_MMX_ASM
-DUSE_3DNOW_ASM -DUSE_SSE_ASM
Run 'gmake' to build Mesa
I'll post a new reply if it has been successful or not.
Regards,
STEVE555
--
View this message in context: http://www.nabble.com/Compiling-problems-with-MESA-from-Git-tp22111678p22120466.html
Sent from the mesa3d-users mailing list archive at Nabble.com.
|
|
From: Brian P. <br...@vm...> - 2009-02-20 15:47:47
|
STEVE555 wrote: > Hi to all, > I'm currently compiling the latest MESA from git.I'm using Fedora > Alpha 11 Rawhide. > I have successfully compiled MESA during the weekend,but the last few days,I > keep getting these errors at the end: > > mklib: Making Linux static library: libutil.a > ar: creating libutil.a > gmake[4]: Leaving directory `/tmp/mesa/src/gallium/auxiliary/util' > gmake[3]: Leaving directory `/tmp/mesa/src/gallium/auxiliary' > gmake[3]: Entering directory `/tmp/mesa/src/gallium/drivers' > gmake[4]: Entering directory `/tmp/mesa/src/gallium/drivers/softpipe' > gmake[4]: Nothing to be done for `default'. > gmake[4]: Leaving directory `/tmp/mesa/src/gallium/drivers/softpipe' > gmake[4]: Entering directory `/tmp/mesa/src/gallium/drivers/failover' > gmake[4]: Nothing to be done for `default'. > gmake[4]: Leaving directory `/tmp/mesa/src/gallium/drivers/failover' > gmake[4]: Entering directory `/tmp/mesa/src/gallium/drivers/trace' > gmake[4]: Nothing to be done for `default'. > gmake[4]: Leaving directory `/tmp/mesa/src/gallium/drivers/trace' > gmake[4]: Entering directory `/tmp/mesa/src/gallium/drivers/i915simple' > gmake[4]: Nothing to be done for `default'. > gmake[4]: Leaving directory `/tmp/mesa/src/gallium/drivers/i915simple' > gmake[4]: Entering directory `/tmp/mesa/src/gallium/drivers/i965simple' > gcc -c -I. -I../../../../src/gallium/include > -I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers > -I../../../../include -g -O2 -Wall -Wmissing-prototypes -std=c99 > -ffast-math -fno-strict-aliasing -m32 -g -fPIC -DUSE_X86_ASM -DUSE_MMX_ASM > -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DDEBUG > -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 brw_surface.c -o brw_surface.o > brw_surface.c: In function ‘brw_surface_copy’: > brw_surface.c:51: error: ‘struct pipe_surface’ has no member named ‘block’ > brw_surface.c:51: error: ‘struct pipe_surface’ has no member named ‘block’ > brw_surface.c:52: error: ‘struct pipe_surface’ has no member named ‘block’ > brw_surface.c:52: error: ‘struct pipe_surface’ has no member named ‘block’ > brw_surface.c:53: error: ‘struct pipe_surface’ has no member named ‘block’ > brw_surface.c:53: error: ‘struct pipe_surface’ has no member named ‘block’ > brw_surface.c:56: error: ‘struct pipe_screen’ has no member named > ‘surface_map’ > brw_surface.c:60: error: ‘struct pipe_screen’ has no member named > ‘surface_map’ > brw_surface.c:65: error: ‘struct pipe_surface’ has no member named ‘block’ > brw_surface.c:66: error: ‘struct pipe_surface’ has no member named ‘stride’ > brw_surface.c:70: error: ‘struct pipe_surface’ has no member named ‘stride’ > brw_surface.c:70: error: ‘struct pipe_surface’ has no member named ‘stride’ > brw_surface.c:73: error: ‘struct pipe_screen’ has no member named > ‘surface_unmap’ > brw_surface.c:74: error: ‘struct pipe_screen’ has no member named > ‘surface_unmap’ > brw_surface.c:79: error: ‘struct pipe_surface’ has no member named ‘block’ > brw_surface.c:80: error: ‘struct pipe_surface’ has no member named ‘block’ > brw_surface.c:83: error: ‘struct pipe_surface’ has no member named ‘block’ > brw_surface.c:84: error: ‘struct pipe_surface’ has no member named ‘stride’ > brw_surface.c:84: error: ‘struct pipe_surface’ has no member named ‘block’ > brw_surface.c:85: error: ‘struct pipe_surface’ has no member named ‘stride’ > brw_surface.c:85: error: ‘struct pipe_surface’ has no member named ‘block’ > brw_surface.c: In function ‘brw_surface_fill’: > brw_surface.c:99: error: ‘struct pipe_screen’ has no member named > ‘surface_map’ > brw_surface.c:103: error: ‘struct pipe_surface’ has no member named ‘block’ > brw_surface.c:103: error: ‘struct pipe_surface’ has no member named ‘stride’ > brw_surface.c:105: error: ‘struct pipe_screen’ has no member named > ‘surface_unmap’ > brw_surface.c:109: error: ‘struct pipe_surface’ has no member named ‘block’ > brw_surface.c:110: error: ‘struct pipe_surface’ has no member named ‘block’ > brw_surface.c:112: error: ‘struct pipe_surface’ has no member named ‘block’ > brw_surface.c:113: error: ‘struct pipe_surface’ has no member named ‘stride’ > brw_surface.c:113: error: ‘struct pipe_surface’ has no member named ‘block’ > gmake[4]: *** [brw_surface.o] Error 1 > gmake[4]: Leaving directory `/tmp/mesa/src/gallium/drivers/i965simple' > gmake[3]: *** [subdirs] Error 1 > gmake[3]: Leaving directory `/tmp/mesa/src/gallium/drivers' > gmake[2]: *** [subdirs] Error 1 > gmake[2]: Leaving directory `/tmp/mesa/src/gallium' > gmake[1]: *** [subdirs] Error 1 > gmake[1]: Leaving directory `/tmp/mesa/src' > gmake: *** [default] Error 1 > [root@localhost mesa]# > > I have been keeping up with the latest updates from Fedora,I use both the > DRM and Nouveau drivers from git as well. > I update these from git on a daily basis. > > The options I parse to configure are: > ./configure --prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin > --libdir=/usr/lib --includedir=/usr/include --build=i686-pc-linux-gnu > --host=i686-pc-linux-gnu --enable-gallium-nouveau --enable-32-bit > --enable-xcb --enable-glx-tls --enable-motif --enable-debug --with-x > --with-expat=/lib > > I hope somebody can help me with this one, > Regards, > STEVE555 The gallium 965 driver should not be build by default with Mesa/master. Are you using autoconf or the traditional make system. Are you sure you have the latest code from git? -Brian |
|
From: STEVE555 <ste...@ho...> - 2009-02-19 23:26:06
|
Hi to all,
I'm currently compiling the latest MESA from git.I'm using Fedora
Alpha 11 Rawhide.
I have successfully compiled MESA during the weekend,but the last few days,I
keep getting these errors at the end:
mklib: Making Linux static library: libutil.a
ar: creating libutil.a
gmake[4]: Leaving directory `/tmp/mesa/src/gallium/auxiliary/util'
gmake[3]: Leaving directory `/tmp/mesa/src/gallium/auxiliary'
gmake[3]: Entering directory `/tmp/mesa/src/gallium/drivers'
gmake[4]: Entering directory `/tmp/mesa/src/gallium/drivers/softpipe'
gmake[4]: Nothing to be done for `default'.
gmake[4]: Leaving directory `/tmp/mesa/src/gallium/drivers/softpipe'
gmake[4]: Entering directory `/tmp/mesa/src/gallium/drivers/failover'
gmake[4]: Nothing to be done for `default'.
gmake[4]: Leaving directory `/tmp/mesa/src/gallium/drivers/failover'
gmake[4]: Entering directory `/tmp/mesa/src/gallium/drivers/trace'
gmake[4]: Nothing to be done for `default'.
gmake[4]: Leaving directory `/tmp/mesa/src/gallium/drivers/trace'
gmake[4]: Entering directory `/tmp/mesa/src/gallium/drivers/i915simple'
gmake[4]: Nothing to be done for `default'.
gmake[4]: Leaving directory `/tmp/mesa/src/gallium/drivers/i915simple'
gmake[4]: Entering directory `/tmp/mesa/src/gallium/drivers/i965simple'
gcc -c -I. -I../../../../src/gallium/include
-I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers
-I../../../../include -g -O2 -Wall -Wmissing-prototypes -std=c99
-ffast-math -fno-strict-aliasing -m32 -g -fPIC -DUSE_X86_ASM -DUSE_MMX_ASM
-DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DDEBUG
-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 brw_surface.c -o brw_surface.o
brw_surface.c: In function ‘brw_surface_copy’:
brw_surface.c:51: error: ‘struct pipe_surface’ has no member named ‘block’
brw_surface.c:51: error: ‘struct pipe_surface’ has no member named ‘block’
brw_surface.c:52: error: ‘struct pipe_surface’ has no member named ‘block’
brw_surface.c:52: error: ‘struct pipe_surface’ has no member named ‘block’
brw_surface.c:53: error: ‘struct pipe_surface’ has no member named ‘block’
brw_surface.c:53: error: ‘struct pipe_surface’ has no member named ‘block’
brw_surface.c:56: error: ‘struct pipe_screen’ has no member named
‘surface_map’
brw_surface.c:60: error: ‘struct pipe_screen’ has no member named
‘surface_map’
brw_surface.c:65: error: ‘struct pipe_surface’ has no member named ‘block’
brw_surface.c:66: error: ‘struct pipe_surface’ has no member named ‘stride’
brw_surface.c:70: error: ‘struct pipe_surface’ has no member named ‘stride’
brw_surface.c:70: error: ‘struct pipe_surface’ has no member named ‘stride’
brw_surface.c:73: error: ‘struct pipe_screen’ has no member named
‘surface_unmap’
brw_surface.c:74: error: ‘struct pipe_screen’ has no member named
‘surface_unmap’
brw_surface.c:79: error: ‘struct pipe_surface’ has no member named ‘block’
brw_surface.c:80: error: ‘struct pipe_surface’ has no member named ‘block’
brw_surface.c:83: error: ‘struct pipe_surface’ has no member named ‘block’
brw_surface.c:84: error: ‘struct pipe_surface’ has no member named ‘stride’
brw_surface.c:84: error: ‘struct pipe_surface’ has no member named ‘block’
brw_surface.c:85: error: ‘struct pipe_surface’ has no member named ‘stride’
brw_surface.c:85: error: ‘struct pipe_surface’ has no member named ‘block’
brw_surface.c: In function ‘brw_surface_fill’:
brw_surface.c:99: error: ‘struct pipe_screen’ has no member named
‘surface_map’
brw_surface.c:103: error: ‘struct pipe_surface’ has no member named ‘block’
brw_surface.c:103: error: ‘struct pipe_surface’ has no member named ‘stride’
brw_surface.c:105: error: ‘struct pipe_screen’ has no member named
‘surface_unmap’
brw_surface.c:109: error: ‘struct pipe_surface’ has no member named ‘block’
brw_surface.c:110: error: ‘struct pipe_surface’ has no member named ‘block’
brw_surface.c:112: error: ‘struct pipe_surface’ has no member named ‘block’
brw_surface.c:113: error: ‘struct pipe_surface’ has no member named ‘stride’
brw_surface.c:113: error: ‘struct pipe_surface’ has no member named ‘block’
gmake[4]: *** [brw_surface.o] Error 1
gmake[4]: Leaving directory `/tmp/mesa/src/gallium/drivers/i965simple'
gmake[3]: *** [subdirs] Error 1
gmake[3]: Leaving directory `/tmp/mesa/src/gallium/drivers'
gmake[2]: *** [subdirs] Error 1
gmake[2]: Leaving directory `/tmp/mesa/src/gallium'
gmake[1]: *** [subdirs] Error 1
gmake[1]: Leaving directory `/tmp/mesa/src'
gmake: *** [default] Error 1
[root@localhost mesa]#
I have been keeping up with the latest updates from Fedora,I use both the
DRM and Nouveau drivers from git as well.
I update these from git on a daily basis.
The options I parse to configure are:
./configure --prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
--libdir=/usr/lib --includedir=/usr/include --build=i686-pc-linux-gnu
--host=i686-pc-linux-gnu --enable-gallium-nouveau --enable-32-bit
--enable-xcb --enable-glx-tls --enable-motif --enable-debug --with-x
--with-expat=/lib
I hope somebody can help me with this one,
Regards,
STEVE555
--
View this message in context: http://www.nabble.com/Compiling-problems-with-MESA-from-Git-tp22111678p22111678.html
Sent from the mesa3d-users mailing list archive at Nabble.com.
|
|
From: Sam E. <em...@ya...> - 2009-02-19 21:17:15
|
Hi, I'm trying to build Mesa with mangled namespace in VC8 as described in the README.WIN32: I've specified the preprocessor flag USE_MGL_NAMESPACE in the project settings, and changed the gl* symbols to mgl* in mesa.def (drivers/windows/gdi/mesa.def). The mesa project of the solution builds ok, but the gdi project gives: error LNK2001: unresolved external symbol _glapi_get_context mesa.def fatal error LNK1120: 1 unresolved externals ...\Mesa-7.3\windows\VC8\mesa\Debug\OPENGL32.lib Would anyone have any ideas? -- View this message in context: http://www.nabble.com/link-error-with-USE_MGL_NAMESPACE-tp22109892p22109892.html Sent from the mesa3d-users mailing list archive at Nabble.com. |
|
From: R. A. K. <rak...@gm...> - 2009-02-19 13:36:49
|
Yout expat must be in non-standard directory. You can explicitly direct it in the configure command line. On Wed, Feb 18, 2009 at 7:32 PM, tom fogal <tf...@al...> wrote: > rp...@uc... writes: > > I installed the expat-1.95.8-9.ppc64.rpm rpm for ppc64 (I'm running fdc7 > > on a PS3) and trying to compile (or at least get the configure file to > > run) for Mesa. Below is the output when I run configure, I'm wondering if > > I even downloaded the right expac.... any ideas anyone? > > You're probably missing a `dev' package. Or you could try expat > version 2+, but the web page seems to indicate that 2.x and 1.95.x are > API-compatible. > > If neither of those help, check your config.log. > > -tom > > > ------------------------------------------------------------------------------ > 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 > _______________________________________________ > Mesa3d-users mailing list > Mes...@li... > https://lists.sourceforge.net/lists/listinfo/mesa3d-users > |
|
From: tom f. <tf...@al...> - 2009-02-19 00:36:11
|
rp...@uc... writes: > I installed the expat-1.95.8-9.ppc64.rpm rpm for ppc64 (I'm running fdc7 > on a PS3) and trying to compile (or at least get the configure file to > run) for Mesa. Below is the output when I run configure, I'm wondering if > I even downloaded the right expac.... any ideas anyone? You're probably missing a `dev' package. Or you could try expat version 2+, but the web page seems to indicate that 2.x and 1.95.x are API-compatible. If neither of those help, check your config.log. -tom |
23 messages has been excluded from this view by a project administrator.
