mesa3d-users

[Mesa3d-users] Problem with Mesa 7.2 (bug?)

[Xavier C. <xa...@wf...>]

Hi,

I have just update Xorg and Mesa to the last "stable" version, but now I
cannot run Compiz or execute a program that use 3d because the screen is
unreadable.

Here is some information of my system, I also attach a screenshot of the
problem:

X.Org X Server 1.5.1
Release Date: 23 September 2008
X Protocol Version 11, Revision 0
Build Operating System: openSUSE SUSE LINUX
Current Operating System: Linux xavier 2.6.25.16-0.1-default #1 SMP
2008-08-21 00:34:25 +0200 i686
Build Date: 23 September 2008  08:52:46PM

...

# lspci | grep -i vga
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960
Integrated Graphics Controller (rev 0c)

...

screenshots:
http://forums.opensuse.org/attachments/screenshots/475d1222384451-problem-xorg-7-4-compiz-screenshot1.jpg
http://forums.opensuse.org/attachments/screenshots/472d1222369570-problem-xorg-7-4-compiz-instantanea46.jpg

/var/log/Xorg.0.log
http://forums.opensuse.org/attachments/screenshots/474d1222383405-problem-xorg-7-4-compiz-xorg.0.log

Also, look at the FPS from the glxgears, to slow (in the screenshot attached).

I will need to downgrade Xorg and Mesa :(

My laptop is a Lenovo Thinkpad T61 running openSUSE 11.

Please help.

Thanks.

-- 
Xavier Callejas

[Mesa3d-users] Mesa 7.2 released

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

This is the newest stable release.

Download from http://sourceforge.net/project/showfiles.php?group_id=3

See the website for release notes:  http://www.mesa3d.org./

-Brian

Re: [Mesa3d-users] GLU on GPU

[Philipp K. K. <pk...@sp...>]

n9ine nvidia engine schrieb:
> Hi all;
> 
> Can glu be run on gpu to make processing faster?

No.

> if not how can I do it? and is is feasable with the actual code?
> 
> 

For your tesselation problem you could use geometr shaders. AFAIK Mesa
doesn't support them yet though.

Philipp

Re: [Mesa3d-users] making tesselation/trimming faster

[Mikael <mik...@te...>]

It look's like you already got the answer in the other thread.

No, you cannot use glu tesselation multithreaded (in terms of running it in parallel), 
I am not sure how you would be able to even try to use it multithreaded but the
error message tells most of it, you call gluEndSurface before you call
gluBeginSUrface.

If it takes a lot of time to do the tesselation it is beacuse you have a huge
amount of triangles being created, you might want to try to change your
geometry to minimize the amount of triangles created.
  ----- Original Message ----- 
  From: n9ine nvidia engine 
  To: mes...@li... 
  Sent: Wednesday, September 17, 2008 9:27 AM
  Subject: [Mesa3d-users] making tesselation/trimming faster


  Hi all;


  I am using glu to tesselate and trimm some nurbs surfaces. But the problrm is that it takes a lot of time to calculate data that will be rendred (vertices , normals). I am taking this data throw callbacks.
  I' am trying to make this multithreaded but I have got this error : "Nurbs Error : gluEndSurface can not preceed gluBeginSurface". An opengl expert tell me that glu do not support multithreading.
  http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=245908#Post245908

  Are there any solution to make it faster? Is the problem with callbacks?

  Kind regards.





------------------------------------------------------------------------------


  -------------------------------------------------------------------------
  This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
  Build the coolest Linux based applications with Moblin SDK & win great prizes
  Grand prize is a trip for two to an Open Source event anywhere in the world
  http://moblin-contest.org/redirect.php?banner_id=100&url=/


------------------------------------------------------------------------------


  _______________________________________________
  Mesa3d-users mailing list
  Mes...@li...
  https://lists.sourceforge.net/lists/listinfo/mesa3d-users

[Mesa3d-users] GLU on GPU

[n9ine n. e. <n9i...@gm...>]

Hi all;

Can glu be run on gpu to make processing faster?
if not how can I do it? and is is feasable with the actual code?


regards

[Mesa3d-users] making tesselation/trimming faster

[n9ine n. e. <n9i...@gm...>]

Hi all;


I am using glu to tesselate and trimm some nurbs surfaces. But the problrm
is that it takes a lot of time to calculate data that will be rendred
(vertices , normals). I am taking this data throw callbacks.
I' am trying to make this multithreaded but I have got this error : "Nurbs
Error : gluEndSurface can not preceed gluBeginSurface". An opengl expert
tell me that glu do not support multithreading.
http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=245908#Post245908

Are there any solution to make it faster? Is the problem with callbacks?

Kind regards.

[Mesa3d-users] newbie question about openchrome

[Rogier S. <r.m...@gm...>]

Hello,

I'm not sure this is supposed to be in the mailing list. I've never used  
one before and I'm not part of the dev team.
I'm just a person with a mesa3d question.

I have grown in love of small quiet computers and in particular via's  
mini-itx
and don't have that much demands in gaming, however,
a certain game called stepmania (I still use version 3.9, but I've tried  
other version and this counts for all versions) does not work
when using EPIA LN(Unichrome Pro/CN700)/ubuntu/openchrome/mesa3d7.0.3.
The game crashes after around three minutes. It just freezes up, the only  
thing I can do then is go to an independant terminal and
if I'm lucky the game unfreezes again (50% chance).
Since I was clueless about what the cause could be, I thought I'd buy an  
EPIA SN, thinking newer is better.

After the discovery of why EPIA SN doesn't work at all and after  
questioning the openchrome group,
I've been told a bug in mesa3d is causing the freeze on the EPIA LN.

I would like to know if this bug is known and how long it will probably  
take before it gets fixed and
what the possible date is that mesa3d will support the Chrome9 HC chipset.  
Will it be months? years?

Greetings,

Roger

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

[Mesa3d-users] GL version in i965 driver [or rather a failure of Mesa/DRI to communicate important info to the user]

[Philipp K. K. <pk...@sp...>]

Both someone on opengl.org and me get this from glxinfo:

OpenGL vendor string: Tungsten Graphics, Inc
OpenGL renderer string: Mesa DRI Intel(R) 965GM 20061102
OpenGL version string: 1.4 Mesa 7.1

I see no error messages with LIBGL_DEBUG=verbose.

Why is the GL version 1.4 instead of 2.1? The i965 driver seems to offer
the necessary extensions (with one exception, see below), there's a
#define need_GL_VERSION_2_1 in the code.

The driver does not advertise GL_ARB_occlusion_query. However there's a
#define need_GL_ARB_occlusion_query in the code and there have been
multiple commits to mesa that claim to have made changes to ARB
occlusion queries in the i965 driver.

Philipp

P.S.:
I now found out about this problem (by looking at the svn changelogs),
however I decided to leave the text above as written to illustrate that
something has to be done about this since it really confuses Mesa users.
Mesa users wonder why they don't get GL 2.1 and Mesa fails at telling
them why.
Occlusion queries need DRM 1.8. Most people seem to have lower versions.

Please give a warning / error message when the DRM version is too low to
support all features supported by the driver, at least when
LIGL_DEBUG=verbose is enabled.

Re: [Mesa3d-users] Mesa 7,1 and OpenGL version?

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

James wrote:
> Hi,
> 
> I am having a couple of problems with Mesa.  I want/need to use OpenGL 2.x,
> but running glxinfo, or programs that check the OpenGL version, would  
> return
> OpenGL 1.4 (Mesa 7.0.3).
> 
> I installed Mesa 7.4, and now have more problems.  The first time I run  
> glxinfo
> after starting X, I get a version string showing Mesa 7.1, but still  
> OpenGL 1.3.
> The second (& subsequent) times, I get an error "Could not find RGB GLX  
> visual",
> and a table of about 20 lines, with hex visual ids, but all the rest of the
> information zeroed out.
> 
> Could someone point me in the direction of whatever information I need to  
> fix
> this?
> 
> Thanks,
> James
> 
> PS: The system's a ThinkPad T61 with Intel 965GM graphics, running OpenSUSE
> 11.0.  Mesa 7.0.3 was installed initially, but I upgraded to 7.1 from a
> repository package.

Even if core Mesa supports the OpenGL 2.1 API, the version reported by 
glGetString(GL_VERSION) depends on the capabilities of the particular 
driver that you're using.  For example, if the driver does not support 
GLSL, then OpenGL 2.x will not be advertised.

In the case of the i965, the i965 driver in Mesa 7.1 and later will 
support GLSL.  I _think_ version 2.0 or 2.1 will then be advertised for 
i965.

-Brian

Re: [Mesa3d-users] How to get statically linked software only Mesa

[Fra <nw...@4o...>]

Brian, thanks for the prompt reply.
I actually tried the autoconf "--enable-static --disable-shared" only after
"make linux-static" didn't work.
In both cases the result is more or less the same, static libraries that do
not contain the OpenGL API.

Any clue?
Thanks!
Francesco



On Thu, 11 Sep 2008 11:49:23 -0600, Brian Paul
<bri...@tu...> wrote:
> Francesco Orsenigo wrote:
>> I'm using Linux (Debian Etch and Ubuntu Hardy).
>>
>> My hardware acceleration does not support FBOs, so, since performance
>> is secondary, I would like to run fully software, and possibly
>> statically link to have a standalone.
>> I still need video output and use hardware acceleration when it does
>> provide FBOs, so I'm not sure OSMesa is an option.
>>
>> But apparently static libraries never contain the basic OpenGL calls.
>> While I understand the rationale for this choice, I would like to know
>> if there is anyway to get around it and have the .a files to make a
>> standalone program that I can run regardless of the system libGL.so
>>
>>
>> I compile with
>>
>> ./configure --with-driver=xlib --enable-static --disable-shared
>> make
>>
>> I get:
>> libGL.a  libGLU.a  libGLw.a  libOSMesa.a
>>
>> None of which contains glBegin(), glVertex() and all the basic GL stuff.
>>
>> Any suggestion is greatly appreciated.
>> Thanks!
> 
> I don't know if the --disable-shared option is actually working with
> autoconf (never tried that one).  But 'make linux-static' might do what
> you want.
> 
> -Brian

[Mesa3d-users] Mesa 7,1 and OpenGL version?

[James <ja...@ch...>]

Hi,

I am having a couple of problems with Mesa.  I want/need to use OpenGL 2.x,
but running glxinfo, or programs that check the OpenGL version, would  
return
OpenGL 1.4 (Mesa 7.0.3).

I installed Mesa 7.4, and now have more problems.  The first time I run  
glxinfo
after starting X, I get a version string showing Mesa 7.1, but still  
OpenGL 1.3.
The second (& subsequent) times, I get an error "Could not find RGB GLX  
visual",
and a table of about 20 lines, with hex visual ids, but all the rest of the
information zeroed out.

Could someone point me in the direction of whatever information I need to  
fix
this?

Thanks,
James

PS: The system's a ThinkPad T61 with Intel 965GM graphics, running OpenSUSE
11.0.  Mesa 7.0.3 was installed initially, but I upgraded to 7.1 from a
repository package.

[Mesa3d-users] Mesa 7.2 release candidate 1

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

Mesa 7.2 will be the new stable release, following the 7.1 development 
release.

The first release candidate is available from http://www.mesa3d.org/beta/

Please test if possible.

-Brian

Re: [Mesa3d-users] How to get statically linked software only Mesa

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

Francesco Orsenigo wrote:
> I'm using Linux (Debian Etch and Ubuntu Hardy).
> 
> My hardware acceleration does not support FBOs, so, since performance
> is secondary, I would like to run fully software, and possibly
> statically link to have a standalone.
> I still need video output and use hardware acceleration when it does
> provide FBOs, so I'm not sure OSMesa is an option.
> 
> But apparently static libraries never contain the basic OpenGL calls.
> While I understand the rationale for this choice, I would like to know
> if there is anyway to get around it and have the .a files to make a
> standalone program that I can run regardless of the system libGL.so
> 
> 
> I compile with
> 
> ./configure --with-driver=xlib --enable-static --disable-shared
> make
> 
> I get:
> libGL.a  libGLU.a  libGLw.a  libOSMesa.a
> 
> None of which contains glBegin(), glVertex() and all the basic GL stuff.
> 
> Any suggestion is greatly appreciated.
> Thanks!

I don't know if the --disable-shared option is actually working with 
autoconf (never tried that one).  But 'make linux-static' might do what 
you want.

-Brian

Re: [Mesa3d-users] Problem in building Mesa

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

Manish wrote:
> Hi Brian
> Thanks for your reply
> Step 1
> I download Souce code from
>                     git clone 
> git://anongit.freedesktop.org/git/mesa/mesa 
> <http://anongit.freedesktop.org/git/mesa/mesa>
> 
> Step 2
>          I modified the makeFile " vi configs/linux-directfb"
>             1) to remove dependency on makedepend
>                       MKDEP = gcc
>                       MKDEP_OPTIONS = -M -o depend
> 
> 
> and 2) To give path of library file like lfusion, ldirectfb
>                    APP_LIB_DEPS  = -L$(TOP)/$(LIB_DIR) -l$(GL_LIB) 
> -l$(GLU_LIB) -l$(GLUT_LIB) -L/usr/local/lib -ldirectfb -ldirect -lfusion
> 
> 
> Step 3
>                   make linux-directfb
> 
>     It seems after that It able to build MesaLib and MesaGlut but it 
> have some problem in building Sample and Demo program.
> Please find error log below
> 
> Thanks a lot
> 
> PS: I am using Scratch Box . My system do not have X.

It looks like all the API entrypoint/dispatch functions are missing from 
libGL.

They should be defined in the libglapi.a lib which is referenced at line 
28 of src/mesa/drivers/directfb/Makefile.  You might run 'nm' on that .a 
and see what you find.

Hopefully you can debug/fix this.

-Brian

[Mesa3d-users] How to get statically linked software only Mesa

[Francesco O. <nw...@4o...>]

I'm using Linux (Debian Etch and Ubuntu Hardy).

My hardware acceleration does not support FBOs, so, since performance
is secondary, I would like to run fully software, and possibly
statically link to have a standalone.
I still need video output and use hardware acceleration when it does
provide FBOs, so I'm not sure OSMesa is an option.

But apparently static libraries never contain the basic OpenGL calls.
While I understand the rationale for this choice, I would like to know
if there is anyway to get around it and have the .a files to make a
standalone program that I can run regardless of the system libGL.so


I compile with

./configure --with-driver=xlib --enable-static --disable-shared
make

I get:
libGL.a  libGLU.a  libGLw.a  libOSMesa.a

None of which contains glBegin(), glVertex() and all the basic GL stuff.

Any suggestion is greatly appreciated.
Thanks!
Francesco

-------------------------------------------------------

Re: [Mesa3d-users] HowTo get Gallium/Cell working/installed

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

Philipp Rosenberger wrote:
> Brian Paul wrote:
>> li...@il... wrote:
>>> Hi,
>>>
>>> I'm trying to run the gallium/cell driver. So colned the mesa git and
>>> checked out the gallium-0.1 branch as described in [1]. Then i ran 'make
>>> linux-cell' with the cell-sdk-3.1-beta. after i installed many
>>> dependencies form the fedora9-ppc tree und changed ppu-gcc, ppu-g++ and
>>> spu-gcc to ppu-gcc43, ppu-g++43 and spu-gcc43 the build went fine.
>>>
>>> no is my problem, how to install this in the system. i want to test 
>>> it in
>>> the simulator for now, but later check on a cell-blade.
>>>
>>> in the simulator runs a fedora9, is it sufficient to copy some files 
>>> from
>>> the build or do i need to build a new xserver with the gallium 
>>> integrated?
>>> is there a document/howto/... wich describs how to integrate gallium in
>>> the system?
>>
>> I haven't really used the Cell simulator yet so you're kind of on your 
>> own.  You shouldn't have to do anything with the X server.
>>
>> Once you've compiled Mesa/gallium, libGL.so contains the Cell driver. 
>> There aren't any other pieces.  You could put libGL.so* in /usr/local/lib
> 
> I only try to use the simulator until my account to access the blades is
> enabled.
> 
> When I compiled the source I did a little mistake, I forgot to change
> spu-gcc to spu-gcc43 and it compiled fine. Then I changed to spu-gcc43
> an I got this error:
> spu-gcc43 -O3 -W -Wall -Winline -Wmissing-prototypes -Wno-main -I.
> -I/opt/cell/sysroot/opt/cell/sdk/usr//spu/include
> -I../../../../../src/mesa/ -I../../../../../src/mesa
> -I../../../../../src/gallium/include
> -I../../../../../src/gallium/auxiliary
> -I../../../../../src/gallium/drivers -DSPU_MAIN_PARAM_LONG_LONG -include
> spu_intrinsics.h -c spu_texture.c
> spu_texture.c: In function 'get_four_texels':
> spu_texture.c:100: error: parameter list does not match a valid
> signature for spu_splats()
> 
> this is line 100 of :
>   const qword tile_size = (qword) spu_splats(sizeof(tile_t));
> 
> spu_splats() is in gcc-4.3 a builtin an does not recognize size_t as
> valid argument-type. I changed the line as follows and it compiled fine.
>   const qword tile_size = (qword) spu_splats((unsigned int)sizeof(tile_t));
> 
> 
> I don't know if this is a good idea to simply cast it  to unsigned int
> or if this is a a bug of the builtin spu_splats().

I don't know the cause, but the cast is fine.  I'll commit it today.

-Brian

Re: [Mesa3d-users] ./configure mesa failed due to X libraries

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

chakradhar thota wrote:
> Hi,
>  
>  
>     I downloaded Mesa 7.1 using git . I doubt makefiles available are 
> generated for x86 architecture.
>     I am working on MIPS and i cant use them for compiling Mesa on my 
> target.
>     So I tried to generate them using "configure" file available with 
> "./configure --build=mipsel-linux --with-x=no".
>     There is no X installed on my target so tried the above option. I 
> want to compile mesa without X support.
>     I got the following errors on running the above command.
>     Do you have any idea about this problem? How can I generate 
> makefiles for mips architecture overcoming the X lib issue?

If you don't have X, I presume you're just interested in off-screen 
rendering with the OSMesa interface.

You can build that configuration on linux with:

make linux-osmesa

You may need to run 'make realclean' first.  The autoconf system 
probably assumes X is always present.

-Brian

[Mesa3d-users] ./configure mesa failed due to X libraries

[chakradhar t. <tho...@gm...>]

Hi,


    I downloaded Mesa 7.1 using git . I doubt makefiles available are
generated for x86 architecture.
    I am working on MIPS and i cant use them for compiling Mesa on my
target.
    So I tried to generate them using "configure" file available with
"./configure --build=mipsel-linux --with-x=no".
    There is no X installed on my target so tried the above option. I want
to compile mesa without X support.
    I got the following errors on running the above command.
     Do you have any idea about this problem? How can I generate makefiles
for mips architecture overcoming the X lib issue?


 ./configure --build=mipsel-linux --with-x=no
checking build system type... mipsel-unknown-linux-gnu
checking host system type... mipsel-unknown-linux-gnu
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 gcc... (cached) 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 g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for gmake... no
checking for make... make
checking for makedepend... no
checking for sed... /scratchbox/tools/bin/sed
checking for pkg-config... /scratchbox/tools/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking whether to enable assembly... no, platform not supported
checking for gcc option to produce PIC... -fPIC
checking for dlopen... no
checking for dlopen in -ldl... yes
checking for posix_memalign... no
checking pkg-config files for X11 are available... no
checking for X... disabled
configure: error: X11 development libraries needed for xlib driver
[sbox-SDK_VERIZON: ~/chakri/mesa] > ./configure --build=mipsel-linux
--with-x=no
checking build system type... mipsel-unknown-linux-gnu
checking host system type... mipsel-unknown-linux-gnu
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 gcc... (cached) 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 g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for gmake... no
checking for make... make
checking for makedepend... no
checking for sed... /scratchbox/tools/bin/sed
checking for pkg-config... /scratchbox/tools/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking whether to enable assembly... no, platform not supported
checking for gcc option to produce PIC... -fPIC
checking for dlopen... no
checking for dlopen in -ldl... yes
checking for posix_memalign... no
checking pkg-config files for X11 are available... no
checking for X... disabled
configure: error: X11 development libraries needed for xlib driver


Thotack

Re: [Mesa3d-users] HowTo get Gallium/Cell working/installed

[Philipp R. <li...@il...>]

Brian Paul wrote:
> li...@il... wrote:
>> Hi,
>>
>> I'm trying to run the gallium/cell driver. So colned the mesa git and
>> checked out the gallium-0.1 branch as described in [1]. Then i ran 'make
>> linux-cell' with the cell-sdk-3.1-beta. after i installed many
>> dependencies form the fedora9-ppc tree und changed ppu-gcc, ppu-g++ and
>> spu-gcc to ppu-gcc43, ppu-g++43 and spu-gcc43 the build went fine.
>>
>> no is my problem, how to install this in the system. i want to test 
>> it in
>> the simulator for now, but later check on a cell-blade.
>>
>> in the simulator runs a fedora9, is it sufficient to copy some files 
>> from
>> the build or do i need to build a new xserver with the gallium 
>> integrated?
>> is there a document/howto/... wich describs how to integrate gallium in
>> the system?
>
> I haven't really used the Cell simulator yet so you're kind of on your 
> own.  You shouldn't have to do anything with the X server.
>
> Once you've compiled Mesa/gallium, libGL.so contains the Cell driver. 
> There aren't any other pieces.  You could put libGL.so* in /usr/local/lib

I only try to use the simulator until my account to access the blades is
enabled.

When I compiled the source I did a little mistake, I forgot to change
spu-gcc to spu-gcc43 and it compiled fine. Then I changed to spu-gcc43
an I got this error:
spu-gcc43 -O3 -W -Wall -Winline -Wmissing-prototypes -Wno-main -I.
-I/opt/cell/sysroot/opt/cell/sdk/usr//spu/include
-I../../../../../src/mesa/ -I../../../../../src/mesa
-I../../../../../src/gallium/include
-I../../../../../src/gallium/auxiliary
-I../../../../../src/gallium/drivers -DSPU_MAIN_PARAM_LONG_LONG -include
spu_intrinsics.h -c spu_texture.c
spu_texture.c: In function 'get_four_texels':
spu_texture.c:100: error: parameter list does not match a valid
signature for spu_splats()

this is line 100 of :
   const qword tile_size = (qword) spu_splats(sizeof(tile_t));

spu_splats() is in gcc-4.3 a builtin an does not recognize size_t as
valid argument-type. I changed the line as follows and it compiled fine.
   const qword tile_size = (qword) spu_splats((unsigned int)sizeof(tile_t));


I don't know if this is a good idea to simply cast it  to unsigned int
or if this is a a bug of the builtin spu_splats().


Kind regards,
Philipp

Re: [Mesa3d-users] HowTo get Gallium/Cell working/installed

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

li...@il... wrote:
> Hi,
> 
> I'm trying to run the gallium/cell driver. So colned the mesa git and
> checked out the gallium-0.1 branch as described in [1]. Then i ran 'make
> linux-cell' with the cell-sdk-3.1-beta. after i installed many
> dependencies form the fedora9-ppc tree und changed ppu-gcc, ppu-g++ and
> spu-gcc to ppu-gcc43, ppu-g++43 and spu-gcc43 the build went fine.
> 
> no is my problem, how to install this in the system. i want to test it in
> the simulator for now, but later check on a cell-blade.
> 
> in the simulator runs a fedora9, is it sufficient to copy some files from
> the build or do i need to build a new xserver with the gallium integrated?
> is there a document/howto/... wich describs how to integrate gallium in
> the system?

I haven't really used the Cell simulator yet so you're kind of on your 
own.  You shouldn't have to do anything with the X server.

Once you've compiled Mesa/gallium, libGL.so contains the Cell driver. 
There aren't any other pieces.  You could put libGL.so* in /usr/local/lib/

-Brian

Re: [Mesa3d-users] Miniglx not found with Mesa-7.1 and other version

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

Manish wrote:
> 
> 
> 
> Hello Everyone,
> I want to Build DirectFBGL using mesa.
> For this I required Miniglx.......I try to download Mesa-7.1 or Mesa-6.5 
> or Mesa-7.0.3
> None of this have MiniGlx inside tar ball.
> 
> But in documentation it says that its there

Miniglx isn't well supported so it's not in the usual tarballs.  You'll 
have to grab the Mesa tree from git.


> as I want to build DirectFBGL my system don't have X related library.
> but I have already ported DirectFB.
> 
> Please tell me if there is any alternative methood.
> 
> I am building it on Mipsel-Linux using Scratch-box
>  
>  
> My second query is ............
> as I want to Port DirectFBGL
> I tried "make linux-directfb" with MesaLib 7.1 it was working fine
> But if I un-tar MesaGlut7.1 or MesaDemo-7.1 then this is not working
> It shows building problem i.e missing makedepend
> Can anyone please suggest how i can build GLUT and Demo without x support
>  
> I will be really Thankful for this

It would help if you'd provide the full/actual text of the error.

-Brian

Re: [Mesa3d-users] MesaGlut with DirectFB

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

Manish wrote:
> Hello Brian
> Can I get That Tarball you mentioned in mail below , So I can build 
> MesaGlut on DirectFb


MesaGLUT-7.0.1.tar.gz is here: 
http://downloads.sourceforge.net/mesa3d/MesaGLUT-7.0.1.tar.gz?modtime=1186149330&big_mirror=0


> I try to check it with latest release 7.1,Its not there

What's not there??

-Brian

> 
> 
> Thanks a lot
> 
> Peter Hanzel wrote:
>  > Hello.
>  >
>  > I am compiling Mesa to work standalone with DirectFB. I run "make
>  > linux-directfb".
>  > It compiles Mesa but for MesaGlut it has no sources for directfb.
>  >
>  > I have downloaded MesaGlut 7.0.1 from sourceforge.
>  >
>  > Than i have checked CVS for Mesa, and there is folder for 
> src\glut\directfb.
>  >
>  > Why it is not in sourceforge MesaGlut-7.0.1.tar.gz.
> 
> Just an oversight. I'll fix it for the next release. I can send you a
> tarball with the files in a bit...
> 
> 
>  > Is there a way to get it. (I can't use CVS. it is blocked.)
> 
> We moved to a git repo last year. CVS is no longer used.
> 
> -Brian
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Mesa3d-users mailing list
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa3d-users

[Mesa3d-users] HowTo get Gallium/Cell working/installed

[<li...@il...>]

Hi,

I'm trying to run the gallium/cell driver. So colned the mesa git and
checked out the gallium-0.1 branch as described in [1]. Then i ran 'make
linux-cell' with the cell-sdk-3.1-beta. after i installed many
dependencies form the fedora9-ppc tree und changed ppu-gcc, ppu-g++ and
spu-gcc to ppu-gcc43, ppu-g++43 and spu-gcc43 the build went fine.

no is my problem, how to install this in the system. i want to test it in
the simulator for now, but later check on a cell-blade.

in the simulator runs a fedora9, is it sufficient to copy some files from
the build or do i need to build a new xserver with the gallium integrated?
is there a document/howto/... wich describs how to integrate gallium in
the system?

Kind regards,

Philipp Rosenberger

[1] http://www.mesa3d.org/cell.html

PS: My english is not so well, I hope you anderstand what i mean.

Re: [Mesa3d-users] MesaGlut with DirectFB

[Manish <idm...@gm...>]

Hello Brian
Can I get That Tarball you mentioned in mail below , So I can build MesaGlut
on DirectFb

I try to check it with latest release 7.1,Its not there


Thanks a lot

Peter Hanzel wrote:
> Hello.
>
> I am compiling Mesa to work standalone with DirectFB. I run "make
> linux-directfb".
> It compiles Mesa but for MesaGlut it has no sources for directfb.
>
> I have downloaded MesaGlut 7.0.1 from sourceforge.
>
> Than i have checked CVS for Mesa, and there is folder for
src\glut\directfb.
>
> Why it is not in sourceforge MesaGlut-7.0.1.tar.gz.

Just an oversight. I'll fix it for the next release. I can send you a
tarball with the files in a bit...


> Is there a way to get it. (I can't use CVS. it is blocked.)

We moved to a git repo last year. CVS is no longer used.

-Brian

[Mesa3d-users] Miniglx not found with Mesa-7.1 and other version

[Manish <idm...@gm...>]

Hello Everyone,
I want to Build DirectFBGL using mesa.
For this I required Miniglx.......I try to download Mesa-7.1 or Mesa-6.5 or
Mesa-7.0.3
None of this have MiniGlx inside tar ball.

But in documentation it says that its there



as I want to build DirectFBGL my system don't have X related library.
but I have already ported DirectFB.

Please tell me if there is any alternative methood.

I am building it on Mipsel-Linux using Scratch-box


My second query is ............
as I want to Port DirectFBGL
I tried "make linux-directfb" with MesaLib 7.1 it was working fine
But if I un-tar MesaGlut7.1 or MesaDemo-7.1 then this is not working
It shows building problem i.e missing makedepend
Can anyone please suggest how i can build GLUT and Demo without x support

I will be really Thankful for this

-- 
With Best Regards