mesa3d-users

Re: [Mesa3d-users] trouble compiling r600 support from 7.6-1 source on Debian

[Cooper Y. <coo...@gm...>]

Try to pull the latest mesa/drm.
Cooper

On Sat, Oct 10, 2009 at 7:09 PM, Arthur Marsh <art...@in...
> wrote:

> Hi, I did an apt-get source mesa and obtained the 7.6 sources, then
> added r600 into debian/rules and attempted to build, but it failed at
> this stage:
>
> gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver
> -I../../../../../include -I../../../../../src/mesa
> -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri
> -I/usr/include/drm    -Wall -g -O2 -Wall -Wmissing-prototypes -std=c99
> -ffast-math -fno-strict-aliasing  -fPIC  -DUSE_X86_64_ASM -D_GNU_SOURCE
> -DPTHREADS -DHAVE_POSIX_MEMALIGN -DGLX_USE_TLS -DPTHREADS
> -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
> -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS  -DCOMPILE_R600 -DR200_MERGED=0
> -DRADEON_COMMON=1 -DRADEON_COMMON_FOR_R600  r600_cmdbuf.c -o r600_cmdbuf.o
> r600_cmdbuf.c: In function ‘r600_cs_emit’:
> r600_cmdbuf.c:331: error: storage size of ‘cs_cmd’ isn’t known
> r600_cmdbuf.c:332: error: array type has incomplete element type
> r600_cmdbuf.c:353: error: ‘RADEON_CHUNK_ID_IB’ undeclared (first use in
> this function)
> r600_cmdbuf.c:353: error: (Each undeclared identifier is reported only once
> r600_cmdbuf.c:353: error: for each function it appears in.)
> r600_cmdbuf.c:358: error: ‘RADEON_CHUNK_ID_RELOCS’ undeclared (first use
> in this function)
> r600_cmdbuf.c:373: error: ‘DRM_RADEON_CS’ undeclared (first use in this
> function)
> r600_cmdbuf.c:332: warning: unused variable ‘cs_chunk’
> r600_cmdbuf.c:331: warning: unused variable ‘cs_cmd’
> make[6]: *** [r600_cmdbuf.o] Error 1
> make[6]: Leaving directory
>
> `/usr/src/sound/mesa-7.6/obj-x86_64-linux-gnu/dri/src/mesa/drivers/dri/r600'
> make[5]: *** [subdirs] Error 1
> make[5]: Leaving directory
> `/usr/src/sound/mesa-7.6/obj-x86_64-linux-gnu/dri/src/mesa/drivers/dri'
> make[4]: *** [default] Error 1
> make[4]: Leaving directory
> `/usr/src/sound/mesa-7.6/obj-x86_64-linux-gnu/dri/src/mesa/drivers'
> make[3]: *** [driver_subdirs] Error 2
> make[3]: Leaving directory
> `/usr/src/sound/mesa-7.6/obj-x86_64-linux-gnu/dri/src/mesa'
> make[2]: *** [subdirs] Error 1
> make[2]: Leaving directory
> `/usr/src/sound/mesa-7.6/obj-x86_64-linux-gnu/dri/src'
> make[1]: *** [default] Error 1
> make[1]: Leaving directory
> `/usr/src/sound/mesa-7.6/obj-x86_64-linux-gnu/dri'
> make: *** [debian/stamp/x86_64-linux-gnu-build-dri] Error 2
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
> debuild: fatal error at line 1324:
> dpkg-buildpackage -rfakeroot -D -us -uc -nc failed
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Mesa3d-users mailing list
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa3d-users
>

[Mesa3d-users] Recent API documentation + ways to get MESA/DRI working in KMS

[Slavko G. <sl...@na...>]

Hello!
Where can i get recent MESA/DRI/DRM API documentation? I keep coming back
to http://dri.sourceforge.net/doc/drm_low_level.html when searching which is
obviously deprecated.

I would like to use OpenGL with the Kernel ModeSetting driver (intel). What
is the simplest way to do this? (just pure opengl, resolution is already
setup, ... ).

Thank you!
Slavko

Re: [Mesa3d-users] trouble compiling r600 support from 7.6-1 source on Debian

[Arthur M. <art...@in...>]

Arthur Marsh wrote, on 2009-10-10 21:39:
> Hi, I did an apt-get source mesa and obtained the 7.6 sources, then 
> added r600 into debian/rules and attempted to build, but it failed at 
> this stage:
> 
> gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver 
> -I../../../../../include -I../../../../../src/mesa 
> -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri 
> -I/usr/include/drm    -Wall -g -O2 -Wall -Wmissing-prototypes -std=c99 
> -ffast-math -fno-strict-aliasing  -fPIC  -DUSE_X86_64_ASM -D_GNU_SOURCE 
> -DPTHREADS -DHAVE_POSIX_MEMALIGN -DGLX_USE_TLS -DPTHREADS 
> -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING 
> -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS  -DCOMPILE_R600 -DR200_MERGED=0 
> -DRADEON_COMMON=1 -DRADEON_COMMON_FOR_R600  r600_cmdbuf.c -o r600_cmdbuf.o
> r600_cmdbuf.c: In function ‘r600_cs_emit’:
> r600_cmdbuf.c:331: error: storage size of ‘cs_cmd’ isn’t known
> r600_cmdbuf.c:332: error: array type has incomplete element type
> r600_cmdbuf.c:353: error: ‘RADEON_CHUNK_ID_IB’ undeclared (first use in 
> this function)
> r600_cmdbuf.c:353: error: (Each undeclared identifier is reported only once
> r600_cmdbuf.c:353: error: for each function it appears in.)
> r600_cmdbuf.c:358: error: ‘RADEON_CHUNK_ID_RELOCS’ undeclared (first use 
> in this function)
> r600_cmdbuf.c:373: error: ‘DRM_RADEON_CS’ undeclared (first use in this 
> function)
> r600_cmdbuf.c:332: warning: unused variable ‘cs_chunk’
> r600_cmdbuf.c:331: warning: unused variable ‘cs_cmd’

(I had previously compiled and installed the xf86-xorg-radeonhd driver 
version 1.3.0 without problems)

I had some success building mesa as per the instructions at: 
http://www.x.org/wiki/radeonhd:experimental_3D

but when it came running the compiled mesa, X started up showing:

(II) AIGLX: Screen 0 is not DRI2 capable

and Xorg.0.log also reported:

(II) RADEONHD(0): EDID for output DVI-D_1
[mi] EQ overflowing. The server is probably stuck in an infinite loop.

Backtrace:
0: /usr/bin/X(xorg_backtrace+0x26) [0x4ee026]
1: /usr/bin/X(mieqEnqueue+0x35b) [0x4cf38b]
2: /usr/bin/X(DGAStealMotionEvent+0x10e) [0x481f4e]
3: /usr/bin/X(xf86PostMotionEventP+0x1c5) [0x493e15]
4: /usr/lib/xorg/modules/input//evdev_drv.so [0x7fd6e4389c81]
5: /usr/bin/X [0x4837b5]
6: /usr/bin/X [0x4750b7]
7: /lib/libpthread.so.0 [0x300100e720]
8: /lib/libc.so.6(ioctl+0x7) [0x30004c54a7]
9: /usr/lib/libdrm.so.2(drmIoctl+0x23) [0x302a203623]
10: /usr/lib/libdrm.so.2(drmGetLock+0x67) [0x302a203837]
11: /usr/lib/xorg/modules/extensions//libdri.so(DRILock+0xed) 
[0x7fd707305cad]
12: /usr/lib/xorg/modules/extensions//libdri.so(DRIDoWakeupHandler+0x3d) 
[0x7fd7
07305d0d]
13: /usr/lib/xorg/modules/extensions//libdri.so(DRIWakeupHandler+0x66) 
[0x7fd707
304e26]
14: /usr/bin/X(WakeupHandler+0x4b) [0x45100b]
15: /usr/bin/X(WaitForSomething+0x1ef) [0x4ebc0f]
16: /usr/bin/X(Dispatch+0xa0) [0x44d180]
17: /usr/bin/X(main+0x3aa) [0x43337a]
18: /lib/libc.so.6(__libc_start_main+0xe6) [0x300041e5c6]
19: /usr/bin/X [0x432819]

(my monitor is just a VGA monitor plugged into the VGA port on the 
computer. The DVI-D (HDMI) port is unused)

glxgears and etracer both failed.

I'm going to restore the stock Debian mesa for now.

Arthur.

[Mesa3d-users] trouble compiling r600 support from 7.6-1 source on Debian

[Arthur M. <art...@in...>]

Hi, I did an apt-get source mesa and obtained the 7.6 sources, then 
added r600 into debian/rules and attempted to build, but it failed at 
this stage:

gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver 
-I../../../../../include -I../../../../../src/mesa 
-I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri 
-I/usr/include/drm    -Wall -g -O2 -Wall -Wmissing-prototypes -std=c99 
-ffast-math -fno-strict-aliasing  -fPIC  -DUSE_X86_64_ASM -D_GNU_SOURCE 
-DPTHREADS -DHAVE_POSIX_MEMALIGN -DGLX_USE_TLS -DPTHREADS 
-DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING 
-DGLX_INDIRECT_RENDERING -DHAVE_ALIAS  -DCOMPILE_R600 -DR200_MERGED=0 
-DRADEON_COMMON=1 -DRADEON_COMMON_FOR_R600  r600_cmdbuf.c -o r600_cmdbuf.o
r600_cmdbuf.c: In function ‘r600_cs_emit’:
r600_cmdbuf.c:331: error: storage size of ‘cs_cmd’ isn’t known
r600_cmdbuf.c:332: error: array type has incomplete element type
r600_cmdbuf.c:353: error: ‘RADEON_CHUNK_ID_IB’ undeclared (first use in 
this function)
r600_cmdbuf.c:353: error: (Each undeclared identifier is reported only once
r600_cmdbuf.c:353: error: for each function it appears in.)
r600_cmdbuf.c:358: error: ‘RADEON_CHUNK_ID_RELOCS’ undeclared (first use 
in this function)
r600_cmdbuf.c:373: error: ‘DRM_RADEON_CS’ undeclared (first use in this 
function)
r600_cmdbuf.c:332: warning: unused variable ‘cs_chunk’
r600_cmdbuf.c:331: warning: unused variable ‘cs_cmd’
make[6]: *** [r600_cmdbuf.o] Error 1
make[6]: Leaving directory 
`/usr/src/sound/mesa-7.6/obj-x86_64-linux-gnu/dri/src/mesa/drivers/dri/r600'
make[5]: *** [subdirs] Error 1
make[5]: Leaving directory 
`/usr/src/sound/mesa-7.6/obj-x86_64-linux-gnu/dri/src/mesa/drivers/dri'
make[4]: *** [default] Error 1
make[4]: Leaving directory 
`/usr/src/sound/mesa-7.6/obj-x86_64-linux-gnu/dri/src/mesa/drivers'
make[3]: *** [driver_subdirs] Error 2
make[3]: Leaving directory 
`/usr/src/sound/mesa-7.6/obj-x86_64-linux-gnu/dri/src/mesa'
make[2]: *** [subdirs] Error 1
make[2]: Leaving directory 
`/usr/src/sound/mesa-7.6/obj-x86_64-linux-gnu/dri/src'
make[1]: *** [default] Error 1
make[1]: Leaving directory 
`/usr/src/sound/mesa-7.6/obj-x86_64-linux-gnu/dri'
make: *** [debian/stamp/x86_64-linux-gnu-build-dri] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
debuild: fatal error at line 1324:
dpkg-buildpackage -rfakeroot -D -us -uc -nc failed

Re: [Mesa3d-users] build difficulties really necessary?

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

Ethan Grammatikidis wrote:
> I'm trying to build mesa with:
>  $ make linux-fbdev
> 
> The build process enters src/gallium/auxiliary/draw where the makedepend command aparently fails. makedepend has it's stderr redirected to /dev/null so I had to do a fair bit of grepping and thinking to get any useful error out of it. Along the way I noticed mention of makedepend in a doc file, but that was fbdev-dri.html. There's no dri on this particular box and I had trouble finding the plain fbdev build amidst all the instructions for a dri/miniglx build, which in turn weren't that easy to find compared to the instructions to build an X or OSMesa build, so by this time I was strictly filtering out any mention of files relating to dri or X, so of course I ignored it several times. What are build instructions needed for Gallium (and, I suspect, all of Mesa) doing only in a file pertaining to fbdev-dri anyway?
> 

The fbdev driver/build hasn't been used much in recent years so I'm 
not surprised there's trouble.  It would be great if you could submit 
patches to fix the build and/or improve the docs.  Sorry I don't have 
time to dig into this now.

-Brian

[Mesa3d-users] build difficulties really necessary?

[Ethan G. <ee...@fa...>]

I'm trying to build mesa with:
 $ make linux-fbdev

The build process enters src/gallium/auxiliary/draw where the makedepend command aparently fails. makedepend has it's stderr redirected to /dev/null so I had to do a fair bit of grepping and thinking to get any useful error out of it. Along the way I noticed mention of makedepend in a doc file, but that was fbdev-dri.html. There's no dri on this particular box and I had trouble finding the plain fbdev build amidst all the instructions for a dri/miniglx build, which in turn weren't that easy to find compared to the instructions to build an X or OSMesa build, so by this time I was strictly filtering out any mention of files relating to dri or X, so of course I ignored it several times. What are build instructions needed for Gallium (and, I suspect, all of Mesa) doing only in a file pertaining to fbdev-dri anyway?

-- 
Ethan Grammatikidis

Those who are slower at parsing information must
necessarily be faster at problem-solving.

[Mesa3d-users] DirectFBGL problems

[Daniel F. <dan...@gm...>]

Hi,
I'm trying use DirectFBGL. I've compiled the source but when I execute the
df_gears I get the follow error:


   ~~~~~~~~~~~~~~~~~~~~~~~~~~| DirectFB 1.4.2 |~~~~~~~~~~~~~~~~~~~~~~~~~~
        (c) 2001-2009  The world wide DirectFB Open Source Community
        (c) 2000-2004  Convergence (integrated media) GmbH
      ----------------------------------------------------------------

(*) DirectFB/Core: Single Application Core. (2009-09-11 14:11)
(!) GLX/Surfaces: Could not find useful visuals!
(!) Core/SurfacePool: Initializing 'GLX Drawables' failed!
    --> Not supported!
(*) Direct/Thread: Started 'X11 Input' (-1) [INPUT OTHER/OTHER 0/0]
<10485760>...
(*) DirectFB/Input: X11 Input 0.1 (directfb.org)
(*) DirectFB/Genefx: MMX detected and enabled
(*) DirectFB/Graphics: OpenGL Acceleration - GeForce 6600/PCI/SSE2 0.5
(Denis Oliver Kropp)
(*) DirectFB/Core/WM: Default 0.3 (directfb.org)
(*) X11/Display: Not using XShm.
(*) X11/Display: Not using XShm.
(*) Direct/Interface: Loaded 'Default' implementation of 'IDirectFBFont'.
(!) Direct/Interface: Unable to dlopen
`/usr/local/lib/directfb-1.4-0/interfaces/IDirectFBGL/libidirectfbgl_mesa.so'!
    -->
/usr/local/lib/directfb-1.4-0/interfaces/IDirectFBGL/libidirectfbgl_mesa.so:
undefined symbol: _mesa_test_proxy_teximage
df_gears.c <344>:
        (#) DirectFBError [primary->GetGL( primary, &primary_gl )]: No
(suitable) implementation found!
 (!!!)  *** WARNING [Application exited without deinitialization of
DirectFB!] *** [core.c:859 in dfb_core_deinit_check()]
 (!!!)  *** WARNING [still objects in 'Layer Region Pool'] *** [object.c:241
in fusion_object_pool_destroy()]
 (!!!)  *** WARNING [still objects in 'Layer Context Pool'] ***
[object.c:241 in fusion_object_pool_destroy()]
 (!!!)  *** WARNING [still objects in 'Surface Pool'] *** [object.c:241 in
fusion_object_pool_destroy()]



I found in source code of _mesa_test_proxy_teximage, but I don't know why
ins't undefined.




-- 
- Livrarei minha mente de todo pensamento fútil e trivial.

Daniel Faustino L. de Souza
M.Sc Candidate in Computer Science
Laboratory of Digital Video Application (LAVID)
Federal University of Paraiba, Brazil
OpenGInga Project

"O bom profissional não é aquele que tem diploma no exterior ou que tem
dúzias de certificações, é simplesmente aquele que ajuda."

Re: [Mesa3d-users] mesa installation problem - linux

[Sergio M. B. <se...@se...>]

Please install all mesa-package and freeglut 
mesa-demos-7.6-0.1.fc11.i586.rpm
mesa-dri-drivers-7.6-0.1.fc11.i586.rpm
mesa-libGL-7.6-0.1.fc11.i586.rpm
mesa-libGL-devel-7.6-0.1.fc11.i586.rpm
mesa-libGLU-7.6-0.1.fc11.i586.rpm
mesa-libGLU-devel-7.6-0.1.fc11.i586.rpm
mesa-libOSMesa-7.6-0.1.fc11.i586.rpm
mesa-libOSMesa-devel-7.6-0.1.fc11.i586.rpm
freeglut-2.4.0-16.fc11.i586.rpm
freeglut-devel-2.4.0-16.fc11.i586.rpm

and dependencies .
may be also :
xorg-x11-server-devel

Mesa, Mesa demos all this , have packages of stable version in yours
favorite distribution .

With package Mesa-demos you could learn  how compile mesa programs , I
don't have any example near to me , sorry ! 


On Mon, 2009-09-28 at 20:34 +0800, Ocean Spring wrote: 
> Dear all,
>  
> yes, my intention is do OpenGL programming under linux. so what should
> i do then.
> and i do need to compile a openGL/Mesa program.
>  
> please give me more advices.
>  
> thank you
>  
> OS
> 
> 
> On Mon, Sep 28, 2009 at 6:08 PM, Adam K Kirchhoff <ad...@vo...>
> wrote:
>         On Mon, 28 Sep 2009 05:57:26 -0400
>         Ocean  Spring <mea...@gm...> wrote:
>         
>         >
>         > and i tried to run some opengl program, it failed. after i
>         read some
>         > articles on Internet, it needs glut.h header file.
>         > then i installed freeglut.
>         >
>         
>         It would be helpful to know what program you are trying to run
>         and what
>         error you are receiving.
>         
>         If you really are just trying to run a program, as compared to
>         compiling one, you almost certainly do not need glut.h.  If
>         you are
>         trying to compile a program, and it does in fact need glut.h,
>         you would
>         have to install the freeglut-devel package.  In Fedora (as
>         with many
>         linux distributions), the header files needed for compiling
>         programs
>         are included in -devel packages, separate from the libraries
>         and
>         binaries needed to run programs.
>         
>         Adam
>         
>         
>         ------------------------------------------------------------------------------
>         Come build with us! The BlackBerry&reg; Developer Conference
>         in SF, CA
>         is the only developer event you need to attend this year.
>         Jumpstart your
>         developing skills, take BlackBerry mobile applications to
>         market and stay
>         ahead of the curve. Join us from November 9&#45;12, 2009.
>         Register now&#33;
>         http://p.sf.net/sfu/devconf
>         _______________________________________________
>         Mesa3d-users mailing list
>         Mes...@li...
>         https://lists.sourceforge.net/lists/listinfo/mesa3d-users 
> 
> 
> 
> 
> -- 
> ---------
> www.vislab.cn 
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________ Mesa3d-users mailing list Mes...@li... https://lists.sourceforge.net/lists/listinfo/mesa3d-users
-- 
Sérgio M. B.

Re: [Mesa3d-users] mesa installation problem - linux

[Ocean S. <mea...@gm...>]

thank you,all. i have fix it.

[liveuser@localhost ~]$ rpm -qa|grep mesa
mesa-libGL-devel-7.6-0.1.fc11.i586
mesa-demos-7.6-0.1.fc11.i586
mesa-dri-drivers-7.6-0.1.fc11.i586
mesa-libGLw-6.5.1-7.fc11.i586
mesa-libGLU-devel-7.6-0.1.fc11.i586
mesa-libGL-7.6-0.1.fc11.i586
mesa-libGLw-devel-6.5.1-7.fc11.i586
mesa-libGLU-7.6-0.1.fc11.i586
[liveuser@localhost ~]$ rpm -qa|grep freeglut
freeglut-2.4.0-16.fc11.i586
freeglut-devel-2.4.0-16.fc11.i586


i am just a bit confused with the runtime and the development package.
i tried it from "Add/Remove Software" in FC 11, and chose the related
packages to install.
after that i am able to compile some, yet not all, of the demos in "progs"
folder.

Thank you!!

OS


On Mon, Sep 28, 2009 at 8:52 AM, Adam K Kirchhoff <ad...@vo...>wrote:

>
> Well to have the necessary headers on your machine, you should install
> freeglut-devel, mesa-libGL-devel, and mesa-libGLU-devel.  Then try compiling
> your program again.
>
> Adam
>
> On Mon, 28 Sep 2009 20:34:25 +0800
> Ocean  Spring <mea...@gm...> wrote:
>
> > Dear all,
> >
> > yes, my intention is do OpenGL programming under linux. so what should i
> do
> > then.
> > and i do need to compile a openGL/Mesa program.
> >
> > please give me more advices.
> >
> > thank you
> >
> > OS
> >
> > On Mon, Sep 28, 2009 at 6:08 PM, Adam K Kirchhoff <ad...@vo...
> >wrote:
> >
> > > On Mon, 28 Sep 2009 05:57:26 -0400
> > > Ocean  Spring <mea...@gm...> wrote:
> > >
> > > >
> > > > and i tried to run some opengl program, it failed. after i read some
> > > > articles on Internet, it needs glut.h header file.
> > > > then i installed freeglut.
> > > >
> > > It would be helpful to know what program you are trying to run and what
> > > error you are receiving.
> > >
> > > If you really are just trying to run a program, as compared to
> > > compiling one, you almost certainly do not need glut.h.  If you are
> > > trying to compile a program, and it does in fact need glut.h, you would
> > > have to install the freeglut-devel package.  In Fedora (as with many
> > > linux distributions), the header files needed for compiling programs
> > > are included in -devel packages, separate from the libraries and
> > > binaries needed to run programs.
> > >
> > > Adam
> > >
> > >
> > >
> > >
> ------------------------------------------------------------------------------
> > > Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> > > is the only developer event you need to attend this year. Jumpstart
> your
> > > developing skills, take BlackBerry mobile applications to market and
> stay
> > > ahead of the curve. Join us from November 9&#45;12, 2009. Register
> now&#33;
> > > http://p.sf.net/sfu/devconf
> > > _______________________________________________
> > > Mesa3d-users mailing list
> > > Mes...@li...
> > > https://lists.sourceforge.net/lists/listinfo/mesa3d-users
> > >
> >
>

Re: [Mesa3d-users] mesa installation problem - linux

[Adam K K. <ad...@vo...>]

Well to have the necessary headers on your machine, you should install freeglut-devel, mesa-libGL-devel, and mesa-libGLU-devel.  Then try compiling your program again.

Adam

On Mon, 28 Sep 2009 20:34:25 +0800
Ocean  Spring <mea...@gm...> wrote:

> Dear all,
> 
> yes, my intention is do OpenGL programming under linux. so what should i do
> then.
> and i do need to compile a openGL/Mesa program.
> 
> please give me more advices.
> 
> thank you
> 
> OS
> 
> On Mon, Sep 28, 2009 at 6:08 PM, Adam K Kirchhoff <ad...@vo...>wrote:
> 
> > On Mon, 28 Sep 2009 05:57:26 -0400
> > Ocean  Spring <mea...@gm...> wrote:
> >
> > >
> > > and i tried to run some opengl program, it failed. after i read some
> > > articles on Internet, it needs glut.h header file.
> > > then i installed freeglut.
> > >
> > It would be helpful to know what program you are trying to run and what
> > error you are receiving.
> >
> > If you really are just trying to run a program, as compared to
> > compiling one, you almost certainly do not need glut.h.  If you are
> > trying to compile a program, and it does in fact need glut.h, you would
> > have to install the freeglut-devel package.  In Fedora (as with many
> > linux distributions), the header files needed for compiling programs
> > are included in -devel packages, separate from the libraries and
> > binaries needed to run programs.
> >
> > Adam
> >
> >
> >
> > ------------------------------------------------------------------------------
> > Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> > is the only developer event you need to attend this year. Jumpstart your
> > developing skills, take BlackBerry mobile applications to market and stay
> > ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> > http://p.sf.net/sfu/devconf
> > _______________________________________________
> > Mesa3d-users mailing list
> > Mes...@li...
> > https://lists.sourceforge.net/lists/listinfo/mesa3d-users
> >
> 
> 
> 
> -- 
> ---------
> www.vislab.cn

Re: [Mesa3d-users] mesa installation problem - linux

[Cooper Y. <coo...@gm...>]

btw, probably you should pull and compile glproto, libdrm etc. after
./autogen.sh you could get some information which tells you what's absent,
if no error output, just run gmake to compile mesa.

Cooper
On Mon, Sep 28, 2009 at 8:49 PM, Cooper Yuan <coo...@gm...> wrote:

> If you are going to compile OpenGL/Mesa, you should pull the latest mesa
> code firstly
> git pull git://anongit.freedesktop.org/mesa/mesa
>
> then run ./autogen.sh and gmake to make the whole mesa.
>
> as you mentioned, if you are going to develop opengl application, I suggest
> that you remove O2 flag in the Makefile.
>
> and in mesa/progs/redbook, you could find some basic application.
>
> Cooper
>
>   On Mon, Sep 28, 2009 at 8:34 PM, Ocean Spring <mea...@gm...>wrote:
>
>> Dear all,
>>
>> yes, my intention is do OpenGL programming under linux. so what should i
>> do then.
>> and i do need to compile a openGL/Mesa program.
>>
>> please give me more advices.
>>
>> thank you
>>
>> OS
>>
>>   On Mon, Sep 28, 2009 at 6:08 PM, Adam K Kirchhoff <ad...@vo...>wrote:
>>
>>> On Mon, 28 Sep 2009 05:57:26 -0400
>>> Ocean  Spring <mea...@gm...> wrote:
>>>
>>> >
>>> > and i tried to run some opengl program, it failed. after i read some
>>> > articles on Internet, it needs glut.h header file.
>>> > then i installed freeglut.
>>> >
>>> It would be helpful to know what program you are trying to run and what
>>> error you are receiving.
>>>
>>> If you really are just trying to run a program, as compared to
>>> compiling one, you almost certainly do not need glut.h.  If you are
>>> trying to compile a program, and it does in fact need glut.h, you would
>>> have to install the freeglut-devel package.  In Fedora (as with many
>>> linux distributions), the header files needed for compiling programs
>>> are included in -devel packages, separate from the libraries and
>>> binaries needed to run programs.
>>>
>>> Adam
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
>>> is the only developer event you need to attend this year. Jumpstart your
>>> developing skills, take BlackBerry mobile applications to market and stay
>>> ahead of the curve. Join us from November 9&#45;12, 2009. Register
>>> now&#33;
>>> http://p.sf.net/sfu/devconf
>>> _______________________________________________
>>> Mesa3d-users mailing list
>>> Mes...@li...
>>> https://lists.sourceforge.net/lists/listinfo/mesa3d-users
>>>
>>
>>
>>
>> --
>> ---------
>> www.vislab.cn
>>
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9&#45;12, 2009. Register
>> now&#33;
>> http://p.sf.net/sfu/devconf
>> _______________________________________________
>> Mesa3d-users mailing list
>> Mes...@li...
>> https://lists.sourceforge.net/lists/listinfo/mesa3d-users
>>
>>
>

Re: [Mesa3d-users] mesa installation problem - linux

[Cooper Y. <coo...@gm...>]

If you are going to compile OpenGL/Mesa, you should pull the latest mesa
code firstly
git pull git://anongit.freedesktop.org/mesa/mesa

then run ./autogen.sh and gmake to make the whole mesa.

as you mentioned, if you are going to develop opengl application, I suggest
that you remove O2 flag in the Makefile.

and in mesa/progs/redbook, you could find some basic application.

Cooper

On Mon, Sep 28, 2009 at 8:34 PM, Ocean Spring <mea...@gm...> wrote:

> Dear all,
>
> yes, my intention is do OpenGL programming under linux. so what should i do
> then.
> and i do need to compile a openGL/Mesa program.
>
> please give me more advices.
>
> thank you
>
> OS
>
>   On Mon, Sep 28, 2009 at 6:08 PM, Adam K Kirchhoff <ad...@vo...>wrote:
>
>> On Mon, 28 Sep 2009 05:57:26 -0400
>> Ocean  Spring <mea...@gm...> wrote:
>>
>> >
>> > and i tried to run some opengl program, it failed. after i read some
>> > articles on Internet, it needs glut.h header file.
>> > then i installed freeglut.
>> >
>> It would be helpful to know what program you are trying to run and what
>> error you are receiving.
>>
>> If you really are just trying to run a program, as compared to
>> compiling one, you almost certainly do not need glut.h.  If you are
>> trying to compile a program, and it does in fact need glut.h, you would
>> have to install the freeglut-devel package.  In Fedora (as with many
>> linux distributions), the header files needed for compiling programs
>> are included in -devel packages, separate from the libraries and
>> binaries needed to run programs.
>>
>> Adam
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9&#45;12, 2009. Register
>> now&#33;
>> http://p.sf.net/sfu/devconf
>> _______________________________________________
>> Mesa3d-users mailing list
>> Mes...@li...
>> https://lists.sourceforge.net/lists/listinfo/mesa3d-users
>>
>
>
>
> --
> ---------
> www.vislab.cn
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Mesa3d-users mailing list
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa3d-users
>
>

Re: [Mesa3d-users] mesa installation problem - linux

[Ocean S. <mea...@gm...>]

Dear all,

yes, my intention is do OpenGL programming under linux. so what should i do
then.
and i do need to compile a openGL/Mesa program.

please give me more advices.

thank you

OS

On Mon, Sep 28, 2009 at 6:08 PM, Adam K Kirchhoff <ad...@vo...>wrote:

> On Mon, 28 Sep 2009 05:57:26 -0400
> Ocean  Spring <mea...@gm...> wrote:
>
> >
> > and i tried to run some opengl program, it failed. after i read some
> > articles on Internet, it needs glut.h header file.
> > then i installed freeglut.
> >
> It would be helpful to know what program you are trying to run and what
> error you are receiving.
>
> If you really are just trying to run a program, as compared to
> compiling one, you almost certainly do not need glut.h.  If you are
> trying to compile a program, and it does in fact need glut.h, you would
> have to install the freeglut-devel package.  In Fedora (as with many
> linux distributions), the header files needed for compiling programs
> are included in -devel packages, separate from the libraries and
> binaries needed to run programs.
>
> Adam
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Mesa3d-users mailing list
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa3d-users
>



-- 
---------
www.vislab.cn

Re: [Mesa3d-users] mesa installation problem - linux

[Adam K K. <ad...@vo...>]

On Mon, 28 Sep 2009 05:57:26 -0400
Ocean  Spring <mea...@gm...> wrote:

> 
> and i tried to run some opengl program, it failed. after i read some
> articles on Internet, it needs glut.h header file.
> then i installed freeglut.
> 
It would be helpful to know what program you are trying to run and what
error you are receiving.  

If you really are just trying to run a program, as compared to
compiling one, you almost certainly do not need glut.h.  If you are
trying to compile a program, and it does in fact need glut.h, you would
have to install the freeglut-devel package.  In Fedora (as with many
linux distributions), the header files needed for compiling programs
are included in -devel packages, separate from the libraries and
binaries needed to run programs.

Adam

Re: [Mesa3d-users] mesa installation problem - linux

[Chia-I Wu <ol...@gm...>]

On Mon, Sep 28, 2009 at 05:57:26AM -0400, Ocean Spring wrote:
> still i don't see any glut.h , gl.h or glu.h and i am still not able to run
> any opengl code.
> please someone enlighten me to run a opengl code under linux.
You don't need the header files if you are "running" an application.
You need the headers if you want to compile an application.  I am not a
Fedora user.  But I guess the headers might be available from the devel
package of freeglut.

You may also want to start with running glxinfo and glxgears.

-- 
Regards,
olv

[Mesa3d-users] mesa installation problem - linux

[Ocean S. <mea...@gm...>]

Dear all,

i have some problem regarding the mesa installation.

i am using fedora core 11.
and mesa is obtained by "yum install"
after i install it, here is some info.

[root@localhost ~]# rpm -qa |grep mesa
mesa-libGLU-7.6-0.1.fc11.i586
mesa-dri-drivers-7.6-0.1.fc11.i586
mesa-libGL-7.6-0.1.fc11.i586

[root@localhost ~]# rpm -ql mesa-libGLU-7.6-0.1.fc11.i586
/usr/lib/libGLU.so.1
/usr/lib/libGLU.so.1.3.070600
[root@localhost ~]# rpm -ql mesa-libGL-7.6-0.1.fc11.i586
/usr/lib/libGL.so.1
/usr/lib/libGL.so.1.2
[root@localhost ~]# rpm -ql mesa-dri-drivers-7.6-0.1.fc11.i586
/usr/lib/dri
/usr/lib/dri/i810_dri.so
/usr/lib/dri/i915_dri.so
/usr/lib/dri/i965_dri.so
/usr/lib/dri/libdricore.so
/usr/lib/dri/mga_dri.so
/usr/lib/dri/r128_dri.so
/usr/lib/dri/r200_dri.so
/usr/lib/dri/r300_dri.so
/usr/lib/dri/radeon_dri.so
/usr/lib/dri/savage_dri.so
/usr/lib/dri/sis_dri.so
/usr/lib/dri/swrast_dri.so
/usr/lib/dri/tdfx_dri.so
/usr/lib/dri/unichrome_dri.so

and i tried to run some opengl program, it failed. after i read some
articles on Internet, it needs glut.h header file.
then i installed freeglut.

[root@localhost ~]# rpm -qa |grep glut
freeglut-2.4.0-16.fc11.i586
[root@localhost ~]# rpm -ql freeglut-2.4.0-16.fc11.i586
/usr/lib/libglut.so.3
/usr/lib/libglut.so.3.8.0
/usr/share/doc/freeglut-2.4.0
/usr/share/doc/freeglut-2.4.0/AUTHORS
/usr/share/doc/freeglut-2.4.0/COPYING
/usr/share/doc/freeglut-2.4.0/ChangeLog
/usr/share/doc/freeglut-2.4.0/INSTALL
/usr/share/doc/freeglut-2.4.0/NEWS
/usr/share/doc/freeglut-2.4.0/README
/usr/share/doc/freeglut-2.4.0/TODO
/usr/share/doc/freeglut-2.4.0/download.html
/usr/share/doc/freeglut-2.4.0/freeglut.html
/usr/share/doc/freeglut-2.4.0/freeglut_logo.png
/usr/share/doc/freeglut-2.4.0/freeglut_user_interface.html
/usr/share/doc/freeglut-2.4.0/index.html
/usr/share/doc/freeglut-2.4.0/ogl_sm.png
/usr/share/doc/freeglut-2.4.0/progress.html
/usr/share/doc/freeglut-2.4.0/structure.html

still i don't see any glut.h , gl.h or glu.h and i am still not able to run
any opengl code.

please someone enlighten me to run a opengl code under linux.

thank you


Ocean

Re: [Mesa3d-users] Compile Mesa on HPUX

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

William F Mitchell wrote:
> I am trying to compile Mesa on an HPUX system and immediately get an 
> error message "Don't know how to make SLANG_SOURCES".  I get this both 
> with autoconf and "make hpux11-32".  The full error message is:
> $ make
> Making sources for autoconf
> Make: Don't know how to make SLANG_SOURCES.  Stop.
> *** Error exit code 1
> 
> Stop.
> *** Error exit code 1
> 
> Stop.
> 
> for autoconf, and
> 
> $ make hpux11-32
>          (cd configs && rm -f current && ln -s hpux11-32 current)
>          make default
> Making sources for hpux11-32
> Make: Don't know how to make SLANG_SOURCES.  Stop.
> *** Error exit code 1
> 
> Stop.
> *** Error exit code 1
> 
> Stop.
> *** Error exit code 1
> 
> Stop.
> 
> using the preexisting config files.
> 
> I haven't been able to find anything searching for that error message. 
> Does anyone know what's wrong?

Hi Bill,

I don't think anyone's built Mesa on HP-UX in a while, but it 
shouldn't be a big chore.

My first hunch is that this is a make/gmake incompatibility.  Do you 
have GNU make on your HP box to try?

Otherwise, I'd debug this by putting some lines like "echo 
$(SLANG_SOURCES)" in src/mesa/Makefile in a few places to see if it's 
properly defined.

Which version of Mesa are you trying?

-Brian

[Mesa3d-users] Compile Mesa on HPUX

[William F M. <wil...@ni...>]

I am trying to compile Mesa on an HPUX system and immediately get an 
error message "Don't know how to make SLANG_SOURCES".  I get this both 
with autoconf and "make hpux11-32".  The full error message is:
$ make
Making sources for autoconf
Make: Don't know how to make SLANG_SOURCES.  Stop.
*** Error exit code 1

Stop.
*** Error exit code 1

Stop.

for autoconf, and

$ make hpux11-32
         (cd configs && rm -f current && ln -s hpux11-32 current)
         make default
Making sources for hpux11-32
Make: Don't know how to make SLANG_SOURCES.  Stop.
*** Error exit code 1

Stop.
*** Error exit code 1

Stop.
*** Error exit code 1

Stop.

using the preexisting config files.

I haven't been able to find anything searching for that error message. 
Does anyone know what's wrong?

Thanks,
Bill
-- 
William F. Mitchell
Mathematical and Computational Sciences Division
National Institute of Standards and Technology
wil...@ni...     http://math.nist.gov/~WMitchell

[Mesa3d-users] MESA3D + DirectFB on Debian

[Daniel F. <dan...@gm...>]

I've compiled mesa3D using directfb (make linux-directfb) on debian lenny.
But the compilation generated a libGl.so.7 with 0 kbytes of size. I don't
know what happened. I can't compile any gl sample, the gcc printf undefined
reference to  gl functions.

Can anyone help-me?

Best Regards

-- 
- Livrarei minha mente de todo pensamento fútil e trivial.

Daniel Faustino L. de Souza
M.Sc Candidate in Computer Science
Laboratory of Digital Video Application (LAVID)
Federal University of Paraiba, Brazil
OpenGInga Project

"O bom profissional não é aquele que tem diploma no exterior ou que tem
dúzias de certificações, é simplesmente aquele que ajuda."

[Mesa3d-users] Mesa7.5.1, Win32, GDI, Rubberbanding/glFlush() Problem

[Randolf S. <ran...@gm...>]

Greetings,

my rubberbanding code fails with Mesa7.5.1/Win32/GDI.
The code draws with XOR directly to the front buffer,
an looks like this:
-snip-
glDrawBuffer(GL_FRONT);
glEnable(GL_COLOR_LOGIC_OP);
glLogicOp(GL_XOR);
glDisable(GL_DEPTH_TEST);

// actual drawing using glBegin() glVertex() and friends omitted

glEnable(GL_DEPTH_TEST);
glLogicOp(GL_COPY);
glDisable(GL_COLOR_LOGIC_OP);
glFlush();
glDrawBuffer(GL_BACK);
-snap-

The rubberband is drawn but immediately cleared.
This is because in
wmesa.c:write_rgba_span_front()
a BitBlt() occurs, that directly draws the rubberband,
and in the glFlush()
wmesa.c:wmesa_flush()
another BitBlt() is done, that erases everything.

Can we maybe check in wmesa_flush() whether
the current buffer is the front buffer and do not do
anything if this is the case (no idea whether this
would affect drawing to the front buffer _without_
logic op enabled, those functions must then also
BitBlt directly...)?
Or should write_rgba_span_front() draw to a different
place, that is later copied to the screen in
wmesa_flush()?

On my side, I can make my code work by omitting
the glFlush(), however, I am hesitant to do so, because
if the application runs over a network, a glFlush()
seems quite appropriate for the special use case of
rubberbanding.

kind regards,
Randolf

Re: [Mesa3d-users] what's the difference between glReadPixels and OSMesaGetDepthBuffer ?

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

Wei Fang wrote:
> 
> hi, all
> 
>       using osmesa to do off screen render, i noticed that glReadPixels 
> and OSMesaGetDepthBuffer can both get the depth buffer. so what's the 
> difference between those two functions. is OSMesaGetDepthBuffer faster?

glReadPixels is a standard GL function while OSMesaGetDepthBuffer is 
specific to Mesa's off-screen interface.  The former copies pixels ou 
to of the color/depth buffer into your own buffer while later returns 
a pointer to the actually depth buffer memory.


>       and another question: how to convert the data getting from 
> OSMesaGetDepthBuffer to float? according to osmesa.h, it's 16bit float. 
> how to convert it to 32bit float?

It's not 16-bit float.  It's either 2 or 4-byte unsigned int (see the 
bytesPerValue parameter).

You could convert a 16-bit ushort to float by dividing by 65535.0

-Brian

[Mesa3d-users] what's the difference between glReadPixels and OSMesaGetDepthBuffer ?

[Wei F. <wei...@gm...>]

hi, all

      using osmesa to do off screen render, i noticed that glReadPixels and
OSMesaGetDepthBuffer can both get the depth buffer. so what's the difference
between those two functions. is OSMesaGetDepthBuffer faster?

      and another question: how to convert the data getting from
OSMesaGetDepthBuffer to float? according to osmesa.h, it's 16bit float. how
to convert it to 32bit float?

      thanks in advance.

Re: [Mesa3d-users] [Mesa3d-dev] wglMakeCurrent possible memory leak

[Karl S. <kar...@gm...>]

On Tue, Sep 8, 2009 at 11:19 AM, José Fonseca <jfo...@vm...> wrote:

> On Tue, 2009-09-08 at 09:20 -0700, Karl Schultz wrote:
> >
> >
> > On Tue, Sep 8, 2009 at 9:17 AM, Brian Paul <br...@vm...> wrote:
> >         Dimitar Kodjabachev wrote:
> >         > Hello,
> >         >
> >         > I sent this to mesa3d-dev, which was probably not the right
> >         place.
> >
> >
> >         mesa3d-dev is OK since there may be a bug in the Mesa wgl
> >         code.  I'm
> >         cc'ing mesa3d-dev.
> >
> >
> >         > I have the following situation (pseudocode) with Mesa 7.4.4:
> >         >
> >         > hglrc1 = wglCreateContext(hdc1)
> >         > wglMakeCurrent(hdc1,hglrc1)
> >         > hglrc2 = wglCreateContext(hdc2)
> >         > wglMakeCurrent(hdc2,hglrc2)
> >         > wglMakeCurrent(hdc3,hglrc2)
> >         > wglDeleteContext(hglrc1)
> >         > wglDeleteContext(hglrc2)
> >         >
> >         > As a result of this sequence of calls, a WMesaFramebuffer
> >         structure is leaked.
> >         > The call causing the leak is wglMakeCurrent(hdc3,hglrc2).
> >         This is what I know
> >         > so far:
> >         >
> >         > -> wglMakeCurrent(hdc3,hglrc2) calls
> >         >  -> WMesaMakeCurrent(hglrc2,hdc3) which calls
> >         >  -> wmesa_lookup_framebuffer(hdc3) which returns NULL, as
> >         the hdc given to
> >         >      wglMakeCurrent is different from the one given at the
> >         time
> >         >      of wglCreateContext
> >         >  -> wmesa_new_framebuffer() is called and a new frame buffer
> >         is allocated
> >         >
> >         > This new frame buffer is not released upon
> >         wglDeleteContext(hglrc2).
> >
> >
> >         A rendering context is not the same as a drawing surface.  So
> >         deleting
> >         a rendering context does not imply deleting a surface.
> >
> >
> >         > As far as
> >         > I know, the device context passed to wglMakeCurrent does not
> >         have to
> >         > be the same as the one passed to wglCreateContext as long as
> >         the the actual
> >         > device and the pixel formats are.  Is this correct or is my
> >         usage wrong?
> >
> >
> >         My understanding is that the context passed to
> >         wglMakeCurrent() must
> >         have been created by a call to wglCreateContext().
> >
> >
> > Right, but there are two contexts passed in wglMakeCurrent().  Here
> > the GL context (rendering context) is hglrc2, created by
> > wglCreateContext().  But the Window context (device context) is hdc3,
> > which is just a Windows Win32 handle.
> >
> >
> >         I don't think I can help with this memory leak.  Maybe someone
> >         else
> >         who works on Windows can help you.
> >
> >
> > The problem is that wglMakeCurrent() will lazily allocate the
> > framebuffer when a device context is made current for the first time.
> > The created framebuffer gets added onto a list and is tagged with the
> > device context that it was just associated with.  When a rendering
> > context is destroyed, this list is searched for a framebuffer tagged
> > with the device context that is current at the time the rendering
> > context was destroyed, and if found, the framebuffer is freed.
> >
> > Note that this conflicts with what Brian said above about deleting
> > surfaces.  I imagine that this was added to wgl as a way to free the
> > framebuffer *somehow*.
> >
> > The leak is caused here because the rendering context is associated
> > with two device contexts.  A framebuffer is created for each device.
> > Later, when the rendering context is destroyed, only one framebuffer
> > is freed, because only one device context can be current when
> > destroying the rendering context, and only the framebuffer tagged with
> > that device context is freed.
> >
> > Since destroying a rendering context shouldn't destroy any surfaces,
> > it isn't an option to tag all framebuffers with the rendering context
> > id and then delete all framebuffers tagged that way when a rendering
> > context is destroyed.  Although this would fix the leak.
> >
> > The right way, I think, is to destroy the framebuffer associated with
> > a device context when the device context is destroyed.  This might
> > involve hooking Windows somehow to get a notification when it is
> > destroyed or setting up a message handler to get WM_DESTROY messages
> > so that we can free resources associated with the device.
> >
> > The wgl code hasn't been all that robust or complete, and I don't know
> > right now if this design/approach is even correct.  I'd have to dig
> > into this more.
> >
> > Right now, I don't have much of a workaround to suggest for the
> > current implementation except to try to destroy hglrc2 and recreate it
> > before making current with hdc3.
> >
> >
> > Karl
>
> What WGL implementation are we talking about here? One of the pure Mesa
> based one in src/mesa/drivers/windows/gdi, or the Gallium based one in
> src/gallium/state_trackers/wgl ?
>
>
I was talking about the former - the pure Mesa one.  I think that the OP was
talking about the same.


> The Gallium WGL state tracker is a faily complete implementation of both
> WGL and ICD interfaces and at least the ICD interface has received a lot
> of testing. The drawback is that the only available driver for it ATM is
> softpipe, which is in generally slower than Mesa's swrast.
>
>
Yes, that implementation of wgl is much better.  It does have a windowproc
to handle resize and destroy events, which frees the framebuffer resources
as I had suggested.


> Jose
>
>

Re: [Mesa3d-users] wglMakeCurrent possible memory leak

[Karl S. <kar...@gm...>]

On Tue, Sep 8, 2009 at 9:17 AM, Brian Paul <br...@vm...> wrote:

> Dimitar Kodjabachev wrote:
> > Hello,
> >
> > I sent this to mesa3d-dev, which was probably not the right place.
>
> mesa3d-dev is OK since there may be a bug in the Mesa wgl code.  I'm
> cc'ing mesa3d-dev.
>
>
> > I have the following situation (pseudocode) with Mesa 7.4.4:
> >
> > hglrc1 = wglCreateContext(hdc1)
> > wglMakeCurrent(hdc1,hglrc1)
> > hglrc2 = wglCreateContext(hdc2)
> > wglMakeCurrent(hdc2,hglrc2)
> > wglMakeCurrent(hdc3,hglrc2)
> > wglDeleteContext(hglrc1)
> > wglDeleteContext(hglrc2)
> >
> > As a result of this sequence of calls, a WMesaFramebuffer structure is
> leaked.
> > The call causing the leak is wglMakeCurrent(hdc3,hglrc2). This is what I
> know
> > so far:
> >
> > -> wglMakeCurrent(hdc3,hglrc2) calls
> >  -> WMesaMakeCurrent(hglrc2,hdc3) which calls
> >  -> wmesa_lookup_framebuffer(hdc3) which returns NULL, as the hdc given
> to
> >      wglMakeCurrent is different from the one given at the time
> >      of wglCreateContext
> >  -> wmesa_new_framebuffer() is called and a new frame buffer is allocated
> >
> > This new frame buffer is not released upon wglDeleteContext(hglrc2).
>
> A rendering context is not the same as a drawing surface.  So deleting
> a rendering context does not imply deleting a surface.
>
>
> > As far as
> > I know, the device context passed to wglMakeCurrent does not have to
> > be the same as the one passed to wglCreateContext as long as the the
> actual
> > device and the pixel formats are.  Is this correct or is my usage wrong?
>
> My understanding is that the context passed to wglMakeCurrent() must
> have been created by a call to wglCreateContext().
>
>
Right, but there are two contexts passed in wglMakeCurrent().  Here the GL
context (rendering context) is hglrc2, created by wglCreateContext().  But
the Window context (device context) is hdc3, which is just a Windows Win32
handle.

I don't think I can help with this memory leak.  Maybe someone else
> who works on Windows can help you.
>
>
The problem is that wglMakeCurrent() will lazily allocate the framebuffer
when a device context is made current for the first time.  The created
framebuffer gets added onto a list and is tagged with the device context
that it was just associated with.  When a rendering context is destroyed,
this list is searched for a framebuffer tagged with the device context that
is current at the time the rendering context was destroyed, and if found,
the framebuffer is freed.

Note that this conflicts with what Brian said above about deleting
surfaces.  I imagine that this was added to wgl as a way to free the
framebuffer *somehow*.

The leak is caused here because the rendering context is associated with two
device contexts.  A framebuffer is created for each device.  Later, when the
rendering context is destroyed, only one framebuffer is freed, because only
one device context can be current when destroying the rendering context, and
only the framebuffer tagged with that device context is freed.

Since destroying a rendering context shouldn't destroy any surfaces, it
isn't an option to tag all framebuffers with the rendering context id and
then delete all framebuffers tagged that way when a rendering context is
destroyed.  Although this would fix the leak.

The right way, I think, is to destroy the framebuffer associated with a
device context when the device context is destroyed.  This might involve
hooking Windows somehow to get a notification when it is destroyed or
setting up a message handler to get WM_DESTROY messages so that we can free
resources associated with the device.

The wgl code hasn't been all that robust or complete, and I don't know right
now if this design/approach is even correct.  I'd have to dig into this
more.

Right now, I don't have much of a workaround to suggest for the current
implementation except to try to destroy hglrc2 and recreate it before making
current with hdc3.


Karl


-Brian
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Mesa3d-users mailing list
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa3d-users
>

Re: [Mesa3d-users] wglMakeCurrent possible memory leak

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

Dimitar Kodjabachev wrote:
> Hello,
> 
> I sent this to mesa3d-dev, which was probably not the right place.

mesa3d-dev is OK since there may be a bug in the Mesa wgl code.  I'm 
cc'ing mesa3d-dev.


> I have the following situation (pseudocode) with Mesa 7.4.4:
> 
> hglrc1 = wglCreateContext(hdc1)
> wglMakeCurrent(hdc1,hglrc1)
> hglrc2 = wglCreateContext(hdc2)
> wglMakeCurrent(hdc2,hglrc2)
> wglMakeCurrent(hdc3,hglrc2)
> wglDeleteContext(hglrc1)
> wglDeleteContext(hglrc2)
> 
> As a result of this sequence of calls, a WMesaFramebuffer structure is leaked.
> The call causing the leak is wglMakeCurrent(hdc3,hglrc2). This is what I know
> so far:
> 
> -> wglMakeCurrent(hdc3,hglrc2) calls
>  -> WMesaMakeCurrent(hglrc2,hdc3) which calls
>  -> wmesa_lookup_framebuffer(hdc3) which returns NULL, as the hdc given to
>      wglMakeCurrent is different from the one given at the time
>      of wglCreateContext
>  -> wmesa_new_framebuffer() is called and a new frame buffer is allocated
> 
> This new frame buffer is not released upon wglDeleteContext(hglrc2).

A rendering context is not the same as a drawing surface.  So deleting 
a rendering context does not imply deleting a surface.


> As far as
> I know, the device context passed to wglMakeCurrent does not have to
> be the same as the one passed to wglCreateContext as long as the the actual
> device and the pixel formats are.  Is this correct or is my usage wrong?

My understanding is that the context passed to wglMakeCurrent() must 
have been created by a call to wglCreateContext().

I don't think I can help with this memory leak.  Maybe someone else 
who works on Windows can help you.

-Brian