mesa3d-users

Re: [Mesa3d-users] Mesa/GL Contexts, glGenTextures and more

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

David Eger wrote:
> Dear Mesa Users,
> 
> I have what I expect is a typical usage scenario, but I'm having a
> hard time getting all of the pieces to fall into place.  I would like
> to use Mesa to load up many textures and models and then use them to
> render images of various resolutions on user request.  My first
> attempt to order things was as follows:
> 
> [A] context = OSMesaCreateContextExt(OSMESA_RGBA, 0, 0, 0, NULL);
> 
> [B] glGenTextures(1, &tex_id1); glBindTexture(GL_TEXTURE_2D, tex_id1); ...
>      glGenTextures(1, &tex_id2); glBindTexture(GL_TEXTURE_2D, tex_id2); ...
> 
> [C] OSMesaMakeCurrent(
>               context, render_buffer, GL_UNSIGNED_BYTE,
>               w, h),
> 
> [D] glMatrixMode(GL_PROJECTION);
>      glLoadIdentity();
>      gluOrtho2D(0.0, (GLfloat)w, 0.0, (GLfloat)h);
>      glMatrixMode(GL_MODELVIEW);
>      glLoadIdentity();
>      glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
>      glBegin(QUADS);...glEnd(); glFlush();
>      glReadPixels()..
> 
> However, I found that repeated calls to glGenTextures() all yielded
> texture id's of 0.

Correct, you must have a currently bound context before calling any gl 
function.


> I then moved the ordering to the following:
> 
> [A] context = OSMesaCreateContextExt(OSMESA_RGBA, 0, 0, 0, NULL);
> 
> [C1] OSMesaMakeCurrent(
>               context, render_buffer, GL_UNSIGNED_BYTE,
>               1, 1),
> 
> [B] glGenTextures(1, &tex_id1); glBindTexture(GL_TEXTURE_2D, tex_id1); ...
>      glGenTextures(1, &tex_id2); glBindTexture(GL_TEXTURE_2D, tex_id2); ...
> 
> [C2] OSMesaMakeCurrent(
>               context, render_buffer, GL_UNSIGNED_BYTE,
>               w, h),
> 
> [D] glMatrixMode(GL_PROJECTION);
>      glLoadIdentity();
>      gluOrtho2D(0.0, (GLfloat)w, 0.0, (GLfloat)h);
>      glMatrixMode(GL_MODELVIEW);
>      glLoadIdentity();
>      glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
>      glBegin(QUADS);...glEnd(); glFlush();
>      glReadPixels()..
> 
> This "fixed" the repeated calls to glGenTextures - they produce
> distinct texture ids as advertised.  However, C2 appears to have only
> partially worked.  The glClear() does indeed wipe all pixels in the
> newly enlarged render buffer, but the output from glBegin()...glEnd()
> is confined to the original 1 pixel!  Is it intended that one cannot
> re-bind a context created with OSMesaCreateContext(Ext) to multiple
> buffers over time?

The first time a rendering context is bound, the viewport and scissor 
bounds are set to the window/drawable size.  So the first call to 
OSMesaMakeCurrent() is setting the viewport/scissor to 1x1.  The second 
call to OSMesaMakeCurrent() does not change the viewport/scissor.

The solution to your problem is to call glViewport(0,0,w,h) after the 
2nd OSMesaMakeCurrent().  Or, pass w,h to the first call, instead of 1,1.

-Brian

[Mesa3d-users] Mesa/GL Contexts, glGenTextures and more

[David E. <eg...@go...>]

Dear Mesa Users,

I have what I expect is a typical usage scenario, but I'm having a
hard time getting all of the pieces to fall into place.  I would like
to use Mesa to load up many textures and models and then use them to
render images of various resolutions on user request.  My first
attempt to order things was as follows:

[A] context = OSMesaCreateContextExt(OSMESA_RGBA, 0, 0, 0, NULL);

[B] glGenTextures(1, &tex_id1); glBindTexture(GL_TEXTURE_2D, tex_id1); ...
     glGenTextures(1, &tex_id2); glBindTexture(GL_TEXTURE_2D, tex_id2); ...

[C] OSMesaMakeCurrent(
              context, render_buffer, GL_UNSIGNED_BYTE,
              w, h),

[D] glMatrixMode(GL_PROJECTION);
     glLoadIdentity();
     gluOrtho2D(0.0, (GLfloat)w, 0.0, (GLfloat)h);
     glMatrixMode(GL_MODELVIEW);
     glLoadIdentity();
     glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
     glBegin(QUADS);...glEnd(); glFlush();
     glReadPixels()..

However, I found that repeated calls to glGenTextures() all yielded
texture id's of 0.  I then moved the ordering to the following:

[A] context = OSMesaCreateContextExt(OSMESA_RGBA, 0, 0, 0, NULL);

[C1] OSMesaMakeCurrent(
              context, render_buffer, GL_UNSIGNED_BYTE,
              1, 1),

[B] glGenTextures(1, &tex_id1); glBindTexture(GL_TEXTURE_2D, tex_id1); ...
     glGenTextures(1, &tex_id2); glBindTexture(GL_TEXTURE_2D, tex_id2); ...

[C2] OSMesaMakeCurrent(
              context, render_buffer, GL_UNSIGNED_BYTE,
              w, h),

[D] glMatrixMode(GL_PROJECTION);
     glLoadIdentity();
     gluOrtho2D(0.0, (GLfloat)w, 0.0, (GLfloat)h);
     glMatrixMode(GL_MODELVIEW);
     glLoadIdentity();
     glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
     glBegin(QUADS);...glEnd(); glFlush();
     glReadPixels()..

This "fixed" the repeated calls to glGenTextures - they produce
distinct texture ids as advertised.  However, C2 appears to have only
partially worked.  The glClear() does indeed wipe all pixels in the
newly enlarged render buffer, but the output from glBegin()...glEnd()
is confined to the original 1 pixel!  Is it intended that one cannot
re-bind a context created with OSMesaCreateContext(Ext) to multiple
buffers over time?

If it helps to know, I'm using Mesa 6.4.2 (it's the default on my system).

-David

Re: [Mesa3d-users] off-screen (OSMesa) anti-aliasing?

[Paul A. T. <pa...@ch...>]

Thanks, Brian! I found some sample code and adapted it to use OSMesa,
and indeed, AA w/ accumulation buffer works fine.

 - Paul

--
=-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
  Paul A.   |     pa...@Ch...
 Thiessen   |  http://www.ChemicalGraphics.com
=-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=

On Friday, October 10, 2008, 1:32:35 PM, Brian Paul wrote:

BP> Paul A. Thiessen wrote:
>> Hi! I'm trying to figure out whether the current mesa (7.2) can do
>> anti-aliasing in off-screen mode, using OSMesa? I'm trying to google
>> etc. for this, and there are some claims that it doesn't do this, but
>> mostly these are very old pages... What's the status of this now?

BP> Do you mean AA with the accumulation buffer?  That should work.

BP> -Brian

Re: [Mesa3d-users] off-screen (OSMesa) anti-aliasing?

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

Paul A. Thiessen wrote:
> Hi! I'm trying to figure out whether the current mesa (7.2) can do
> anti-aliasing in off-screen mode, using OSMesa? I'm trying to google
> etc. for this, and there are some claims that it doesn't do this, but
> mostly these are very old pages... What's the status of this now?

Do you mean AA with the accumulation buffer?  That should work.

-Brian

[Mesa3d-users] off-screen (OSMesa) anti-aliasing?

[Paul A. T. <pa...@ch...>]

Hi! I'm trying to figure out whether the current mesa (7.2) can do
anti-aliasing in off-screen mode, using OSMesa? I'm trying to google
etc. for this, and there are some claims that it doesn't do this, but
mostly these are very old pages... What's the status of this now?

Thanks,

 - Paul

=-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
  Paul A.   |     pa...@Ch...
 Thiessen   |  http://www.ChemicalGraphics.com
=-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=

Re: [Mesa3d-users] "mesa.def" linker error

[Karl S. <k.w...@co...>]

I guess you can either go back to the actual 7.2 release, which should work,
or you could try just removing that symbol from mesa.def.  Perhaps someone
made a change that removed that function from the mesa library.  This isn't
uncommon.  Whenever functions are added or removed, there are several files
in the Windows build that need to be updated rather manually.  Ideally, we
could have some scripts that generate these files.  But in practice, we
usually wait until a release and then catch the files up.

If you determine that removing that symbol from the mesa.def file is the
right solution, let us know and Brian will usually update it.

Thanks.

On Thu, Oct 9, 2008 at 6:46 PM, Littlebob <lit...@gm...> wrote:

> Whoops, I thought I had given all the info.
>
> Yes, I was using the VC8 project files and the latest commit from the
> GIT repository.(Oct 8)
>
> Does mesa3d have any external dependencies?
>
>
> On Thu, Oct 9, 2008 at 6:49 PM, Karl Schultz <k.w...@co...>
> wrote:
> > I'm fairly sure that the latest version (VC8) of the visual project files
> > worked with the 7.2 release because I tested the beta and no changes were
> > required.
> >
> > We should probably remove the VC6 and VC7 project files, since they are
> not
> > being maintained.
> >
> > It would be helpful if you specify which project files and mesa release
> you
> > were using.
> >
> > On Wed, Oct 8, 2008 at 7:34 PM, Littlebob <lit...@gm...> wrote:
> >>
> >> When trying to compile the latest version of the MS windows GDI driver
> >> (software) mesa3d I am getting a linker error:
> >>
> >> >>  Linking...
> >> >>  mesa.def : error LNK2001: unresolved external symbol
> >> >> _glapi_get_proc_address
> >> >>  .\Release/OPENGL32.lib : fatal error LNK1120: 1 unresolved externals
> >>
> >> Since the last time I compiled, there were a lot of file changes, so
> >> have the MS visual project files been updated? (if needed)
> >> Or, has the "mesa.def" file not been updated?
> >> Any ideas?
> >>
> >> Thank you.
> >
> >
>

Re: [Mesa3d-users] "mesa.def" linker error

[Littlebob <lit...@gm...>]

Whoops, I thought I had given all the info.

Yes, I was using the VC8 project files and the latest commit from the
GIT repository.(Oct 8)

Does mesa3d have any external dependencies?


On Thu, Oct 9, 2008 at 6:49 PM, Karl Schultz <k.w...@co...> wrote:
> I'm fairly sure that the latest version (VC8) of the visual project files
> worked with the 7.2 release because I tested the beta and no changes were
> required.
>
> We should probably remove the VC6 and VC7 project files, since they are not
> being maintained.
>
> It would be helpful if you specify which project files and mesa release you
> were using.
>
> On Wed, Oct 8, 2008 at 7:34 PM, Littlebob <lit...@gm...> wrote:
>>
>> When trying to compile the latest version of the MS windows GDI driver
>> (software) mesa3d I am getting a linker error:
>>
>> >>  Linking...
>> >>  mesa.def : error LNK2001: unresolved external symbol
>> >> _glapi_get_proc_address
>> >>  .\Release/OPENGL32.lib : fatal error LNK1120: 1 unresolved externals
>>
>> Since the last time I compiled, there were a lot of file changes, so
>> have the MS visual project files been updated? (if needed)
>> Or, has the "mesa.def" file not been updated?
>> Any ideas?
>>
>> Thank you.
>
>

Re: [Mesa3d-users] "mesa.def" linker error

[Karl S. <k.w...@co...>]

I'm fairly sure that the latest version (VC8) of the visual project files
worked with the 7.2 release because I tested the beta and no changes were
required.

We should probably remove the VC6 and VC7 project files, since they are not
being maintained.

It would be helpful if you specify which project files and mesa release you
were using.

On Wed, Oct 8, 2008 at 7:34 PM, Littlebob <lit...@gm...> wrote:

> When trying to compile the latest version of the MS windows GDI driver
> (software) mesa3d I am getting a linker error:
>
> >>  Linking...
> >>  mesa.def : error LNK2001: unresolved external symbol
> _glapi_get_proc_address
> >>  .\Release/OPENGL32.lib : fatal error LNK1120: 1 unresolved externals
>
> Since the last time I compiled, there were a lot of file changes, so
> have the MS visual project files been updated? (if needed)
> Or, has the "mesa.def" file not been updated?
> Any ideas?
>
> Thank you.
>
> -------------------------------------------------------------------------
> 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] "mesa.def" linker error

[Littlebob <lit...@gm...>]

When trying to compile the latest version of the MS windows GDI driver
(software) mesa3d I am getting a linker error:

>>  Linking...
>>  mesa.def : error LNK2001: unresolved external symbol _glapi_get_proc_address
>>  .\Release/OPENGL32.lib : fatal error LNK1120: 1 unresolved externals

Since the last time I compiled, there were a lot of file changes, so
have the MS visual project files been updated? (if needed)
Or, has the "mesa.def" file not been updated?
Any ideas?

Thank you.

Re: [Mesa3d-users] GL_POLYGON_STIPPLE is broken?

[Svilen K. <kru...@go...>]

Brian,*
*
I filled-up a bug - here is the link*
*http://bugs.freedesktop.org/show_bug.cgi?id=17957

The amazing thing is that there is a quite similar bug filled-up 3 years ago
and still unassigned.

I truly hope that this one will be luckier. I'm ready for a release (toped),
but this is really stopping me, because my packages on fc9 will not be fully
functional. It seems that all distros are affected, but fc9 currently has to
stick to DRI drives and Mesa for ATI. There is no alternative there.

I'll appreciate your help! Even if it is simply a link to appropriate
people...

Regards
Svilen

On Tue, Oct 7, 2008 at 2:32 PM, Svilen Krustev <
kru...@go...> wrote:

> OK Brian,
>
> I'll do that
>
>
> On Tue, Oct 7, 2008 at 2:24 PM, Brian Paul <
> bri...@tu...> wrote:
>
>> Svilen Krustev wrote:
>>
>>> Hi,
>>>
>>> I can't get a polygon stipple to work on Fedora core 9. Please see the
>>> example - it is not mine - I just picked it up from the net at random. I
>>> have the same effect myself in a "slightly" bigger application.
>>>
>>> The latest mesa in fc9 is 7.1. I'm with ATI card.
>>>
>>> Your help will highly appreciated guys!
>>>
>>
>> I'd suggest filing a bug in bugzilla.  Please indicate which driver you're
>> using (see glxinfo).  Maybe one of the ATI developers will be able to help
>> you.
>>
>> -Brian
>>
>>
>

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

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

I don't recall if I replied to you before, but I fixed the problem with 
building static libs yesterday.  It'll be in Mesa 7.2.1, or you can get 
the latest code from git, or you can apply the attached patch.

-Brian

Fra wrote:
> 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
> 
> 
> -------------------------------------------------------------------------
> 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
> 

Re: [Mesa3d-users] Mesa Software Rendering + Compiz possible?

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

Mesa supports GLX_EXT_texture_from_pixmap in software, but may have some 
open issues.  I haven't tried it with compiz.

Someone on the mesa3d-dev list might be able to say more.  I don't think 
many Mesa developers are on this list.

-Brian


thacrazze wrote:
> No idea?
> 
> 2008/10/5 thacrazze <tha...@go...>:
>> Hello,
>>
>> is it possible to use Compiz with the Mesa Software Renderer? And when not, why?
>>
>> thacrazze
>>
> 
> -------------------------------------------------------------------------
> 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
> 

Re: [Mesa3d-users] GL_POLYGON_STIPPLE is broken?

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

You're probably most likely to get help by posting to the mesa3d-dev 
list and hoping one of the r300 developers can help you.  I don't have a 
r300 card.

-Brian


Svilen Krustev wrote:
> Brian,*
> *
> I filled-up a bug - here is the link*
> *http://bugs.freedesktop.org/show_bug.cgi?id=17957
> 
> The amazing thing is that there is a quite similar bug filled-up 3 years 
> ago and still unassigned.
> 
> I truly hope that this one will be luckier. I'm ready for a release 
> (toped), but this is really stopping me, because my packages on fc9 will 
> not be fully functional. It seems that all distros are affected, but fc9 
> currently has to stick to DRI drives and Mesa for ATI. There is no 
> alternative there.
> 
> I'll appreciate your help! Even if it is simply a link to appropriate 
> people...
> 
> Regards
> Svilen
> 
> On Tue, Oct 7, 2008 at 2:32 PM, Svilen Krustev 
> <kru...@go... <mailto:kru...@go...>> 
> wrote:
> 
>     OK Brian,
> 
>     I'll do that
> 
> 
>     On Tue, Oct 7, 2008 at 2:24 PM, Brian Paul
>     <bri...@tu...
>     <mailto:bri...@tu...>> wrote:
> 
>         Svilen Krustev wrote:
> 
>             Hi,
> 
>             I can't get a polygon stipple to work on Fedora core 9.
>             Please see the example - it is not mine - I just picked it
>             up from the net at random. I have the same effect myself in
>             a "slightly" bigger application.
> 
>             The latest mesa in fc9 is 7.1. I'm with ATI card.
> 
>             Your help will highly appreciated guys!
> 
> 
>         I'd suggest filing a bug in bugzilla.  Please indicate which
>         driver you're using (see glxinfo).  Maybe one of the ATI
>         developers will be able to help you.
> 
>         -Brian
> 
> 
> 

Re: [Mesa3d-users] Mesa Software Rendering + Compiz possible?

[thacrazze <tha...@go...>]

No idea?

2008/10/5 thacrazze <tha...@go...>:
> Hello,
>
> is it possible to use Compiz with the Mesa Software Renderer? And when not, why?
>
> thacrazze
>

Re: [Mesa3d-users] GL_POLYGON_STIPPLE is broken?

[Svilen K. <kru...@go...>]

OK Brian,

I'll do that

On Tue, Oct 7, 2008 at 2:24 PM, Brian Paul
<bri...@tu...>wrote:

> Svilen Krustev wrote:
>
>> Hi,
>>
>> I can't get a polygon stipple to work on Fedora core 9. Please see the
>> example - it is not mine - I just picked it up from the net at random. I
>> have the same effect myself in a "slightly" bigger application.
>>
>> The latest mesa in fc9 is 7.1. I'm with ATI card.
>>
>> Your help will highly appreciated guys!
>>
>
> I'd suggest filing a bug in bugzilla.  Please indicate which driver you're
> using (see glxinfo).  Maybe one of the ATI developers will be able to help
> you.
>
> -Brian
>
>

Re: [Mesa3d-users] GL_POLYGON_STIPPLE is broken?

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

Svilen Krustev wrote:
> Hi,
> 
> I can't get a polygon stipple to work on Fedora core 9. Please see the 
> example - it is not mine - I just picked it up from the net at random. I 
> have the same effect myself in a "slightly" bigger application.
> 
> The latest mesa in fc9 is 7.1. I'm with ATI card.
> 
> Your help will highly appreciated guys!

I'd suggest filing a bug in bugzilla.  Please indicate which driver 
you're using (see glxinfo).  Maybe one of the ATI developers will be 
able to help you.

-Brian

[Mesa3d-users] GL_POLYGON_STIPPLE is broken?

[Svilen K. <kru...@go...>]

// StipplingPolygons.cpp : Defines the entry point for the console application.
// Ercan Polat: 02/04/2008
// Note: This program is an example of "OpenGL Programming Guide (Third Edition)". I did
// add a stippling part with my initials (EP). 
// Project Description: This project creates a simple OpenGl window using GLUT library.
// The program is an example of stipple patterns used on rectangle polygons.

//#include "stdafx.h"
#include  <GL/glx.h>
#include  <GL/gl.h>
#include  <GL/glut.h>

// function that creates the stipple patterns and rectanguale polygons.
void display(void)
{
    // Stipple pattern of my initials (EP)
GLubyte myInitial[] = {
    0xff, 0x01, 0x00, 0x01, 0x00, 0x01, 0x00, 0x01,
    0x00, 0x01, 0x00, 0x01, 0x00, 0x01, 0x00, 0x01,
    0x00, 0x01, 0x00, 0x01, 0x00, 0x01, 0x00, 0x01,
    0x00, 0x01, 0x00, 0x01, 0x00, 0x01, 0x00, 0x01,
    0x00, 0x01, 0x00, 0x01, 0x00, 0x01, 0x00, 0x01,
    0x00, 0x01, 0x00, 0x01, 0x00, 0x01, 0x00, 0x01,
    0x00, 0x01, 0x00, 0x01, 0x00, 0x01, 0x00, 0x01,
    0x00, 0x01, 0x00, 0x01, 0x00, 0x01, 0x00, 0x01,
    0xff, 0x01, 0xff, 0x01, 0x00, 0x01, 0x01, 0x01,
    0x00, 0x01, 0x01, 0x01, 0x00, 0x01, 0x01, 0x01,
    0x00, 0x01, 0x01, 0x01, 0x00, 0x01, 0x01, 0x01,
    0x00, 0x01, 0x01, 0x01, 0x00, 0x01, 0x01, 0x01,
    0x00, 0x01, 0x01, 0x01, 0x00, 0x01, 0x01, 0x01,
    0x00, 0x01, 0x01, 0x01, 0x00, 0x01, 0x01, 0x01,
    0xff, 0x00, 0xFF, 0x01, 0x00, 0x00, 0x00, 0x00,
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,};

    // A stipple pattern of a fly
GLubyte fly[] = {
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
    0x03, 0x80, 0x01, 0xC0, 0x06, 0xC0, 0x03, 0x60,
    0x04, 0x60, 0x06, 0x20, 0x04, 0x30, 0x0C, 0x20,
    0x04, 0x18, 0x18, 0x20, 0x04, 0x0C, 0x30, 0x20,
    0x04, 0x06, 0x60, 0x20, 0x44, 0x03, 0xC0, 0x22,
    0x44, 0x01, 0x80, 0x22, 0x44, 0x01, 0x80, 0x22,
    0x44, 0x01, 0x80, 0x22, 0x44, 0x01, 0x80, 0x22,
    0x44, 0x01, 0x80, 0x22, 0x44, 0x01, 0x80, 0x22,
    0x66, 0x01, 0x80, 0x66, 0x33, 0x01, 0x80, 0xCC,
    0x19, 0x81, 0x81, 0x98, 0x0C, 0xC1, 0x83, 0x30,
    0x07, 0xe1, 0x87, 0xe0, 0x03, 0x3f, 0xfc, 0xc0,
    0x03, 0x31, 0x8c, 0xc0, 0x03, 0x33, 0xcc, 0xc0,
    0x06, 0x64, 0x26, 0x60, 0x0c, 0xcc, 0x33, 0x30,
    0x18, 0xcc, 0x33, 0x18, 0x10, 0xc4, 0x23, 0x08,
    0x10, 0x63, 0xC6, 0x08, 0x10, 0x30, 0x0c, 0x08,
    0x10, 0x18, 0x18, 0x08, 0x10, 0x00, 0x00, 0x08};

    // Another stipple pattern
GLubyte halftone[] = {
    0xAA, 0xAA, 0xAA, 0xAA, 0x55, 0x55, 0x55, 0x55,
    0xAA, 0xAA, 0xAA, 0xAA, 0x55, 0x55, 0x55, 0x55,
    0xAA, 0xAA, 0xAA, 0xAA, 0x55, 0x55, 0x55, 0x55,
    0xAA, 0xAA, 0xAA, 0xAA, 0x55, 0x55, 0x55, 0x55,
    0xAA, 0xAA, 0xAA, 0xAA, 0x55, 0x55, 0x55, 0x55,
    0xAA, 0xAA, 0xAA, 0xAA, 0x55, 0x55, 0x55, 0x55,
    0xAA, 0xAA, 0xAA, 0xAA, 0x55, 0x55, 0x55, 0x55,
    0xAA, 0xAA, 0xAA, 0xAA, 0x55, 0x55, 0x55, 0x55,
    0xAA, 0xAA, 0xAA, 0xAA, 0x55, 0x55, 0x55, 0x55,
    0xAA, 0xAA, 0xAA, 0xAA, 0x55, 0x55, 0x55, 0x55,
    0xAA, 0xAA, 0xAA, 0xAA, 0x55, 0x55, 0x55, 0x55,
    0xAA, 0xAA, 0xAA, 0xAA, 0x55, 0x55, 0x55, 0x55,
    0xAA, 0xAA, 0xAA, 0xAA, 0x55, 0x55, 0x55, 0x55,
    0xAA, 0xAA, 0xAA, 0xAA, 0x55, 0x55, 0x55, 0x55,
    0xAA, 0xAA, 0xAA, 0xAA, 0x55, 0x55, 0x55, 0x55,
    0xAA, 0xAA, 0xAA, 0xAA, 0x55, 0x55, 0x55, 0x55};

    // Clear the Color Buffer
    glClear(GL_COLOR_BUFFER_BIT);
    glColor4f(1.0, 1.0, 1.0, 0.5);        // Set the color to white 
    // draw one solid, unstippled rectangle
    glRectf(25.0, 25.0, 120.0, 120.0);
    glEnable(GL_POLYGON_STIPPLE);          // Enable POLYGON STIPPLE
    glPolygonStipple(fly);                   // Pass the stipple arrray 
    glColor3f(0.0, 1.0, 0.0);        // Set the color to white 
    glRectf (130.0, 25.0, 220.0, 120.0);   // draw the first rectangle with the first stipple
    glColor3f(1.0, 0.0, 0.0);        // Set the color to white 
    glPolygonStipple(halftone);               // pass the second stipple array
    glRectf(230.0, 25.0, 320.0, 120.0);    // draw the rectangle
    
    // My own code starts here
    glColor3f(0.0, 0.0,1.0);            // Set change the color to red  
    glPolygonStipple(myInitial);        // Pass the stipple my initial (EP) 
    glRectf(25.0, 130.0, 325.0, 220.0); // Draw a bigger rectangle
    glDisable(GL_POLYGON_STIPPLE);      // Disable the POLYGON STIPPLE
    glFlush();
}
void init (void)
{
    glClearColor(0.0, 0.0, 0.0, 0.0);    // Clear the backround set it to black
    glShadeModel(GL_FLAT);                 // set the shading model to FLAT
}
// Function that resets the window, each time when the window size is changed
void reshape(int w, int h)
{
    glViewport (0, 0, (GLsizei) w, (GLsizei) h);    
    glMatrixMode (GL_PROJECTION);
    glLoadIdentity ();
    gluOrtho2D (0.0, (GLdouble) w, 0.0, (GLdouble) h);
}
// Main entry point of the program
int main(int argc, char** argv)
{
    glutInit(&argc, argv);
    glutInitDisplayMode(GLUT_SINGLE | GLUT_RGB); 
    glutInitWindowSize(350, 250);    // set up the window size
    glutCreateWindow(argv[0]);       // create the window
    init();                          // initiliaze the window
    glutDisplayFunc(display);        // call the display to draw the rectangles
    glutReshapeFunc(reshape);        // call the reshape function (each time when the window size is changed)
    glutMainLoop();
    return 0;
}  

Re: [Mesa3d-users] Static build broken

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

Randolf Schultz wrote:
> Greetings,
> 
> probably due to a bug in libtool the static Mesa3D build (for atleast Linux)
> is currently broken (Mesa3D 7.2). After
> make linux-x86-static
> one gets static libraries that do not contain vital symbols (glVertex** and
> the like). This is because libtool somehow creates an ar archive with
> other ar archives as members (and ld can not handle archives in archives).
> 
> One can manually extract/remove the offending archives, extract all objects
> from them and add those objects to libGL.a with ar to make it work.

I've fixed this in git.  Patch attached.

-Brian

Re: [Mesa3d-users] compilation errors, /usr/bin/ld: cannot find -lXi, and so on

[jiasheng d. <di...@ho...>]

Hi,  Cami:

    I am new to Linux. I typed two commands "find" and "yum" on my system. The following is the output. It seems to me that I have the libraries installed, but the mesa compiling does not recognize the name of the library or which directory the library resides in. Thanks.

Sincerely,
Diao Jiasheng 
  
[root@ lib]#  find / -name "libXi*"
/usr/lib64/libXinerama.so.1.0.0
/usr/lib64/libXi.so.6
/usr/lib64/libXi.so.6.0.0
/usr/lib64/libXinerama.so.1
/usr/share/doc/libXinerama-1.0.1
/usr/share/doc/libXi-1.0.1
/usr/lib/libXinerama.so.1.0.0
/usr/lib/libXi.so.6
/usr/lib/libXi.so.6.0.0
/usr/lib/libXinerama.so.1
/var/cache/yum/rhel-x86_64-client-workstation-5/headers/libXinerama-devel-1.0.1-2.1.x86_64.hdr
/var/cache/yum/rhel-x86_64-client-workstation-5/headers/libXi-devel-1.0.1-3.1.x86_64.hdr


[root@ lib]# yum provides libXi
Loading "rhnplugin" plugin
rhel-x86_64-client-workst 100% |=========================| 1.4 kB    00:00     
rhel-x86_64-client-5      100% |=========================| 1.4 kB    00:00     
libXi.i386 : X.Org X11 libXi runtime library

libXi.x86_64 : X.Org X11 libXi runtime library

libXi.i386 : X.Org X11 libXi runtime library
libXi.x86_64 : X.Org X11 libXi runtime library



----------------------------------------
> Date: Sun, 5 Oct 2008 21:08:05 +0200
> From: fra...@fr...
> To: di...@ho...
> CC: mes...@li...
> Subject: Re: [Mesa3d-users] compilation errors, /usr/bin/ld: cannot find -lXi, and so on
> 
> 
> Hi Diao,
> 
> A "yum provides libXi" on my EL5 gives me the following result :
> libXi.i386 : X.Org X11 libXi runtime library
> libXi.x86_64 : X.Org X11 libXi runtime library
> 
> By the way, 2.6.18-8.el5 is completely outdated...
> 
> Best,
> 
> Francois
> 
> 
> On Sun, 5 Oct 2008 14:45:54 -0400
> jiasheng diao  wrote:
> 
>> Hi, All:
>> 
>>      On a linux system I am compiling Mesa 7.2 including the three files: MesaDemos-7.2.tar  MesaGLUT-7.2.tar  MesaLib-7.2.tar.
>>      uname -a gives me the following information on my system.
>>      Linux  2.6.18-8.el5 #1 SMP Fri Jan 26 14:15:14 EST 2007 x86_64 x86_64 x86_64 GNU/Linux
>>      I used "make linux-x86-64" for compilation.
>>     
>> The following is the end of compilation output. What should I do next?
>> Do my computer miss some library or the library exists somewhere else
>> which can not be found by gcc? Thanks.
>> 
>> Sincerely,
>> Diao Jiasheng
>> ----------------------------------------------------------------------------------------------------------------------------------------------------
>>  /bin/sh ../../../bin/mklib -o glut -linker 'gcc' -ldflags '' \
>>                 -major 3 -minor 7 -patch 1 \
>>                  -install ../../../lib64 \
>>                 -id /usr/local/lib64/libglut.3.dylib \
>>                
>> -L../../../lib64 -lGLU -lGL -L/usr/X11R6/lib64 -lX11 -lXmu -lXi -lm
>> glut_8x13.o glut_9x15.o glut_bitmap.o glut_bwidth.o glut_cindex.o
>> glut_cmap.o glut_cursor.o glut_dials.o glut_dstr.o glut_event.o
>> glut_ext.o glut_fcb.o glut_fullscrn.o glut_gamemode.o glut_get.o
>> glut_glxext.o glut_hel10.o glut_hel12.o glut_hel18.o glut_init.o
>> glut_input.o glut_joy.o glut_key.o glut_keyctrl.o glut_keyup.o
>> glut_menu.o glut_menu2.o glut_mesa.o glut_modifier.o glut_mroman.o
>> glut_overlay.o glut_roman.o glut_shapes.o glut_space.o glut_stroke.o
>> glut_swap.o glut_swidth.o glut_tablet.o glut_teapot.o glut_tr10.o
>> glut_tr24.o glut_util.o glut_vidresize.o glut_warp.o glut_win.o
>> glut_winmisc.o layerutil.o
>> mklib: Making Linux shared library:  libglut.so.3.7.1
>> /usr/bin/ld: cannot find -lXi
>> collect2: ld returned 1 exit status
>> mklib: Installing libglut.so.3.7.1 libglut.so.3 libglut.so in ../../../lib64
>> mv: cannot stat `libglut.so.3.7.1': No such file or directory
>> make[3]: *** [../../../lib64/libglut.so] Error 1
>> make[3]: Leaving directory `/home/diao/Mesa/Mesa-7.2/src/glut/glx'
>> make[2]: *** [subdirs] Error 1
>> make[2]: Leaving directory `/home/diao/Mesa/Mesa-7.2/src'
>> make[1]: *** [default] Error 1
>> make[1]: Leaving directory `/home/diao/Mesa/Mesa-7.2'
>> make: *** [linux-x86-64] Error 2
>> 
>> 
>> _________________________________________________________________
>> Stay up to date on your PC, the Web, and your mobile phone with Windows Live.
>> http://clk.atdmt.com/MRT/go/msnnkwxp1020093185mrt/direct/01/

_________________________________________________________________
Get more out of the Web. Learn 10 hidden secrets of Windows Live.
http://windowslive.com/connect/post/jamiethomson.spaces.live.com-Blog-cns!550F681DAD532637!5295.entry?ocid=TXT_TAGLM_WL_domore_092008

[Mesa3d-users] Static build broken

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

Greetings,

probably due to a bug in libtool the static Mesa3D build (for atleast Linux)
is currently broken (Mesa3D 7.2). After
make linux-x86-static
one gets static libraries that do not contain vital symbols (glVertex** and
the like). This is because libtool somehow creates an ar archive with
other ar archives as members (and ld can not handle archives in archives).

One can manually extract/remove the offending archives, extract all objects
from them and add those objects to libGL.a with ar to make it work.

kind regards,
Randolf

[Mesa3d-users] three questions

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

Hello All,

Three questions,

When will mesa3d support Chrome9/Chrome9 HC/Chrome9 HC3?

On wikipedia it says that Gallium3d will replace mesa3d, is that true?

When will gallium3d support Chrome9/Chrome9 HC/Chrome9 HC3?

Sincerely,

Rogier Sluimers

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

Re: [Mesa3d-users] compilation errors, /usr/bin/ld: cannot find -lXi, and so on

[FD C. <fra...@fr...>]

Hi Diao,

A "yum provides libXi" on my EL5 gives me the following result :
libXi.i386 : X.Org X11 libXi runtime library
libXi.x86_64 : X.Org X11 libXi runtime library

By the way, 2.6.18-8.el5 is completely outdated...

Best,

Francois


On Sun, 5 Oct 2008 14:45:54 -0400
jiasheng diao <di...@ho...> wrote:

> Hi, All:
> 
>      On a linux system I am compiling Mesa 7.2 including the three files: MesaDemos-7.2.tar  MesaGLUT-7.2.tar  MesaLib-7.2.tar.
>      uname -a gives me the following information on my system.
>      Linux  2.6.18-8.el5 #1 SMP Fri Jan 26 14:15:14 EST 2007 x86_64 x86_64 x86_64 GNU/Linux
>      I used "make linux-x86-64" for compilation.
>     
> The following is the end of compilation output. What should I do next?
> Do my computer miss some library or the library exists somewhere else
> which can not be found by gcc? Thanks.
> 
> Sincerely,
> Diao Jiasheng
> ----------------------------------------------------------------------------------------------------------------------------------------------------
>  /bin/sh ../../../bin/mklib -o glut -linker 'gcc' -ldflags '' \
>                 -major 3 -minor 7 -patch 1 \
>                  -install ../../../lib64 \
>                 -id /usr/local/lib64/libglut.3.dylib \
>                
> -L../../../lib64 -lGLU -lGL -L/usr/X11R6/lib64 -lX11 -lXmu -lXi -lm
> glut_8x13.o glut_9x15.o glut_bitmap.o glut_bwidth.o glut_cindex.o
> glut_cmap.o glut_cursor.o glut_dials.o glut_dstr.o glut_event.o
> glut_ext.o glut_fcb.o glut_fullscrn.o glut_gamemode.o glut_get.o
> glut_glxext.o glut_hel10.o glut_hel12.o glut_hel18.o glut_init.o
> glut_input.o glut_joy.o glut_key.o glut_keyctrl.o glut_keyup.o
> glut_menu.o glut_menu2.o glut_mesa.o glut_modifier.o glut_mroman.o
> glut_overlay.o glut_roman.o glut_shapes.o glut_space.o glut_stroke.o
> glut_swap.o glut_swidth.o glut_tablet.o glut_teapot.o glut_tr10.o
> glut_tr24.o glut_util.o glut_vidresize.o glut_warp.o glut_win.o
> glut_winmisc.o layerutil.o
> mklib: Making Linux shared library:  libglut.so.3.7.1
> /usr/bin/ld: cannot find -lXi
> collect2: ld returned 1 exit status
> mklib: Installing libglut.so.3.7.1 libglut.so.3 libglut.so in ../../../lib64
> mv: cannot stat `libglut.so.3.7.1': No such file or directory
> make[3]: *** [../../../lib64/libglut.so] Error 1
> make[3]: Leaving directory `/home/diao/Mesa/Mesa-7.2/src/glut/glx'
> make[2]: *** [subdirs] Error 1
> make[2]: Leaving directory `/home/diao/Mesa/Mesa-7.2/src'
> make[1]: *** [default] Error 1
> make[1]: Leaving directory `/home/diao/Mesa/Mesa-7.2'
> make: *** [linux-x86-64] Error 2
> 
> 
> _________________________________________________________________
> Stay up to date on your PC, the Web, and your mobile phone with Windows Live.
> http://clk.atdmt.com/MRT/go/msnnkwxp1020093185mrt/direct/01/

[Mesa3d-users] compilation errors, /usr/bin/ld: cannot find -lXi, and so on

[jiasheng d. <di...@ho...>]

Hi, All:

     On a linux system I am compiling Mesa 7.2 including the three files: MesaDemos-7.2.tar  MesaGLUT-7.2.tar  MesaLib-7.2.tar.
     uname -a gives me the following information on my system.
     Linux  2.6.18-8.el5 #1 SMP Fri Jan 26 14:15:14 EST 2007 x86_64 x86_64 x86_64 GNU/Linux
     I used "make linux-x86-64" for compilation.
    
The following is the end of compilation output. What should I do next?
Do my computer miss some library or the library exists somewhere else
which can not be found by gcc? Thanks.

Sincerely,
Diao Jiasheng
----------------------------------------------------------------------------------------------------------------------------------------------------
 /bin/sh ../../../bin/mklib -o glut -linker 'gcc' -ldflags '' \
                -major 3 -minor 7 -patch 1 \
                 -install ../../../lib64 \
                -id /usr/local/lib64/libglut.3.dylib \
               
-L../../../lib64 -lGLU -lGL -L/usr/X11R6/lib64 -lX11 -lXmu -lXi -lm
glut_8x13.o glut_9x15.o glut_bitmap.o glut_bwidth.o glut_cindex.o
glut_cmap.o glut_cursor.o glut_dials.o glut_dstr.o glut_event.o
glut_ext.o glut_fcb.o glut_fullscrn.o glut_gamemode.o glut_get.o
glut_glxext.o glut_hel10.o glut_hel12.o glut_hel18.o glut_init.o
glut_input.o glut_joy.o glut_key.o glut_keyctrl.o glut_keyup.o
glut_menu.o glut_menu2.o glut_mesa.o glut_modifier.o glut_mroman.o
glut_overlay.o glut_roman.o glut_shapes.o glut_space.o glut_stroke.o
glut_swap.o glut_swidth.o glut_tablet.o glut_teapot.o glut_tr10.o
glut_tr24.o glut_util.o glut_vidresize.o glut_warp.o glut_win.o
glut_winmisc.o layerutil.o
mklib: Making Linux shared library:  libglut.so.3.7.1
/usr/bin/ld: cannot find -lXi
collect2: ld returned 1 exit status
mklib: Installing libglut.so.3.7.1 libglut.so.3 libglut.so in ../../../lib64
mv: cannot stat `libglut.so.3.7.1': No such file or directory
make[3]: *** [../../../lib64/libglut.so] Error 1
make[3]: Leaving directory `/home/diao/Mesa/Mesa-7.2/src/glut/glx'
make[2]: *** [subdirs] Error 1
make[2]: Leaving directory `/home/diao/Mesa/Mesa-7.2/src'
make[1]: *** [default] Error 1
make[1]: Leaving directory `/home/diao/Mesa/Mesa-7.2'
make: *** [linux-x86-64] Error 2


_________________________________________________________________
Stay up to date on your PC, the Web, and your mobile phone with Windows Live.
http://clk.atdmt.com/MRT/go/msnnkwxp1020093185mrt/direct/01/

[Mesa3d-users] Mesa Software Rendering + Compiz possible?

[thacrazze <tha...@go...>]

Hello,

is it possible to use Compiz with the Mesa Software Renderer? And when not, why?

thacrazze

[Mesa3d-users] [7.3] Configure problem, "gcc: '-V' option must have argument"

[Clemens E. <lin...@gm...>]

Hi,

I am trying to build xorg-git using the script published on the xorg-wiki.
The build fails duing mesa-configure with the message: "gcc: '-V'
option must have argument".
I had a look into gcc's manual it it really seems to expect some
argument if that option is passed.

I tried to build it on Feodra8 and Ubuntu-8.04 (gcc-4.2.3).

Any ideas howto fix thix?

Thank you in advance, Clemens