mesa3d-users

Re: [Mesa3d-users] tnl/t_draw.c:205: bind_inputs: Assertion `inputs[i]->BufferObj->Pointer' failed.

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

Utkarsh Ayachit wrote:
> Brian Paul wrote:
>> Utkarsh Ayachit wrote:
>>> Brian,
>>>
>>> If I build ParaView with debian-lenny (gcc 4.3) can you run it (or do 
>>> you prefer debian-etch?
>>
>> Hmmm, I don't have any debian installations here.  Pretty much just 
>> fedora.
>>
>> My 64-bit system has fedora 9.
>>
>> -Brian
>>
>>
> 
> This is built using gcc-4.1. Let me know if you cannot run it.
> 
> http://paraview.org/files/v3.3/ForBrian/paraview-3.3.1-Linux-x86_64.tar.gz
> 
> To reproduce the bug do the following:
> * start ./bin/paraview
> * From the "Sources" menu, select "Sphere"
> * Hit the "Apply" button on the properties page (lower left dock 
> window). You;ll see a sphere rendered
> * From the "Filters" menu, select "Common|Clip". A clip plane widget 
> will be shown over the sphere
> * On the properties tab (below the Apply button), there's a "Show Plane" 
> check box. Just keep on toggling it for a while. After a few (sometimes 
> just a couple, other times several) toggles, paraview will crash with:
> 
> paraview-real: tnl/t_draw.c:203: bind_inputs: Assertion 
> `inputs[i]->BufferObj->Pointer' failed.

OK, I'm getting the assertion here.  I'll try to debug it tomorrow...

-Brian

Re: [Mesa3d-users] tnl/t_draw.c:205: bind_inputs: Assertion `inputs[i]->BufferObj->Pointer' failed.

[Utkarsh A. <utk...@ki...>]

Brian Paul wrote:
> Utkarsh Ayachit wrote:
>> Brian,
>>
>> If I build ParaView with debian-lenny (gcc 4.3) can you run it (or do 
>> you prefer debian-etch?
> 
> Hmmm, I don't have any debian installations here.  Pretty much just fedora.
> 
> My 64-bit system has fedora 9.
> 
> -Brian
> 
> 

This is built using gcc-4.1. Let me know if you cannot run it.

http://paraview.org/files/v3.3/ForBrian/paraview-3.3.1-Linux-x86_64.tar.gz

To reproduce the bug do the following:
* start ./bin/paraview
* From the "Sources" menu, select "Sphere"
* Hit the "Apply" button on the properties page (lower left dock 
window). You;ll see a sphere rendered
* From the "Filters" menu, select "Common|Clip". A clip plane widget 
will be shown over the sphere
* On the properties tab (below the Apply button), there's a "Show Plane" 
check box. Just keep on toggling it for a while. After a few (sometimes 
just a couple, other times several) toggles, paraview will crash with:

paraview-real: tnl/t_draw.c:203: bind_inputs: Assertion 
`inputs[i]->BufferObj->Pointer' failed.

Utkarsh

Re: [Mesa3d-users] tnl/t_draw.c:205: bind_inputs: Assertion `inputs[i]->BufferObj->Pointer' failed.

[Utkarsh A. <utk...@ki...>]

Brian Paul wrote:
> Utkarsh Ayachit wrote:
>>
>>
>> Brian Paul wrote:
>>> Utkarsh Ayachit wrote:
>>>> Hi Brian,
>>>>
>>>> I am trying to come up with a small test case that reproduces this 
>>>> issue that we are having with ParaView using Mesa 7.1 (as well as 
>>>> git-Mesa) on a 64 bit debian box.
>>>>
>>>> The assertion fails following repeated creation/deletion of display 
>>>> lists (ofcourse when display lists are not used, everything is peachy).
>>>>
>>>> For debugging purposes I put a printf as follows in tnl/t_draw.c:
>>>>
>>>> static void bind_inputs( GLcontext *ctx,
>>>>              const struct gl_client_array *inputs[],
>>>>              GLint count,
>>>>              struct gl_buffer_object **bo,
>>>>              GLuint *nr_bo )
>>>> {
>>>>     ...
>>>>     for (i = 0; i < VERT_ATTRIB_MAX; i++) {
>>>>        const void *ptr;
>>>>
>>>>        if (inputs[i]->BufferObj->Name) {
>>>>      if (!inputs[i]->BufferObj->Pointer) {
>>>>         ...
>>>>             printf("i : %i\n", i);
>>>>         printf("name: %i\n", inputs[i]->BufferObj->Name);
>>>>         assert(inputs[i]->BufferObj->Pointer);
>>>>      }
>>>>     ...
>>>> }
>>>>
>>>> On successful runs it looks like:
>>>> i : 0
>>>> name: 1
>>>> i : 0
>>>> name: 1
>>>> i : 31
>>>> name: 1
>>>>
>>>> However when the assertion fails, the output is:
>>>> i : 0
>>>> name: 1
>>>> i : 31
>>>> name: 10999
>>>>
>>>> Not sure that's very helpful, perhaps you can point me in the right 
>>>> direction for producing more relevant debug output.
>>>
>>> I haven't seen that one before.  Do you happen to have a small test 
>>> program that I could try here?  I think I've got a 64-bit Linux 
>>> install here somewhere...
>>>
>>> You might also try running with valgrind to see if it finds anything.
>>
>> I am attaching the output from valgrind. There indeed are a few 
>> suspicious invalid writes.
>>
>> The crash is very random, I am still trying to isolate the cause to 
>> write out a small example.
> 
> I haven't been able to reproduce this with any hacked demos here.
> 
> Do you want to send me a ParaView binary?
> 
Sure thing. I am creating one right now.

Utkarsh

Re: [Mesa3d-users] tnl/t_draw.c:205: bind_inputs: Assertion `inputs[i]->BufferObj->Pointer' failed.

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

Utkarsh Ayachit wrote:
> 
> 
> Brian Paul wrote:
>> Utkarsh Ayachit wrote:
>>> Hi Brian,
>>>
>>> I am trying to come up with a small test case that reproduces this 
>>> issue that we are having with ParaView using Mesa 7.1 (as well as 
>>> git-Mesa) on a 64 bit debian box.
>>>
>>> The assertion fails following repeated creation/deletion of display 
>>> lists (ofcourse when display lists are not used, everything is peachy).
>>>
>>> For debugging purposes I put a printf as follows in tnl/t_draw.c:
>>>
>>> static void bind_inputs( GLcontext *ctx,
>>>              const struct gl_client_array *inputs[],
>>>              GLint count,
>>>              struct gl_buffer_object **bo,
>>>              GLuint *nr_bo )
>>> {
>>>     ...
>>>     for (i = 0; i < VERT_ATTRIB_MAX; i++) {
>>>        const void *ptr;
>>>
>>>        if (inputs[i]->BufferObj->Name) {
>>>      if (!inputs[i]->BufferObj->Pointer) {
>>>         ...
>>>             printf("i : %i\n", i);
>>>         printf("name: %i\n", inputs[i]->BufferObj->Name);
>>>         assert(inputs[i]->BufferObj->Pointer);
>>>      }
>>>     ...
>>> }
>>>
>>> On successful runs it looks like:
>>> i : 0
>>> name: 1
>>> i : 0
>>> name: 1
>>> i : 31
>>> name: 1
>>>
>>> However when the assertion fails, the output is:
>>> i : 0
>>> name: 1
>>> i : 31
>>> name: 10999
>>>
>>> Not sure that's very helpful, perhaps you can point me in the right 
>>> direction for producing more relevant debug output.
>>
>> I haven't seen that one before.  Do you happen to have a small test 
>> program that I could try here?  I think I've got a 64-bit Linux 
>> install here somewhere...
>>
>> You might also try running with valgrind to see if it finds anything.
> 
> I am attaching the output from valgrind. There indeed are a few 
> suspicious invalid writes.
> 
> The crash is very random, I am still trying to isolate the cause to 
> write out a small example.

I haven't been able to reproduce this with any hacked demos here.

Do you want to send me a ParaView binary?

-Brian

Re: [Mesa3d-users] tnl/t_draw.c:205: bind_inputs: Assertion `inputs[i]->BufferObj->Pointer' failed.

[Utkarsh A. <utk...@ki...>]

Brian Paul wrote:
> Utkarsh Ayachit wrote:
>> Hi Brian,
>>
>> I am trying to come up with a small test case that reproduces this 
>> issue that we are having with ParaView using Mesa 7.1 (as well as 
>> git-Mesa) on a 64 bit debian box.
>>
>> The assertion fails following repeated creation/deletion of display 
>> lists (ofcourse when display lists are not used, everything is peachy).
>>
>> For debugging purposes I put a printf as follows in tnl/t_draw.c:
>>
>> static void bind_inputs( GLcontext *ctx,
>>              const struct gl_client_array *inputs[],
>>              GLint count,
>>              struct gl_buffer_object **bo,
>>              GLuint *nr_bo )
>> {
>>     ...
>>     for (i = 0; i < VERT_ATTRIB_MAX; i++) {
>>        const void *ptr;
>>
>>        if (inputs[i]->BufferObj->Name) {
>>      if (!inputs[i]->BufferObj->Pointer) {
>>         ...
>>     
>>         printf("i : %i\n", i);
>>         printf("name: %i\n", inputs[i]->BufferObj->Name);
>>         assert(inputs[i]->BufferObj->Pointer);
>>      }
>>     ...
>> }
>>
>> On successful runs it looks like:
>> i : 0
>> name: 1
>> i : 0
>> name: 1
>> i : 31
>> name: 1
>>
>> However when the assertion fails, the output is:
>> i : 0
>> name: 1
>> i : 31
>> name: 10999
>>
>> Not sure that's very helpful, perhaps you can point me in the right 
>> direction for producing more relevant debug output.
> 
> I haven't seen that one before.  Do you happen to have a small test 
> program that I could try here?  I think I've got a 64-bit Linux install 
> here somewhere...
> 
> You might also try running with valgrind to see if it finds anything.

I am attaching the output from valgrind. There indeed are a few 
suspicious invalid writes.

The crash is very random, I am still trying to isolate the cause to 
write out a small example.

Utkarsh

Re: [Mesa3d-users] tnl/t_draw.c:205: bind_inputs: Assertion `inputs[i]->BufferObj->Pointer' failed.

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

Utkarsh Ayachit wrote:
> Hi Brian,
> 
> I am trying to come up with a small test case that reproduces this issue 
> that we are having with ParaView using Mesa 7.1 (as well as git-Mesa) on 
> a 64 bit debian box.
> 
> The assertion fails following repeated creation/deletion of display 
> lists (ofcourse when display lists are not used, everything is peachy).
> 
> For debugging purposes I put a printf as follows in tnl/t_draw.c:
> 
> static void bind_inputs( GLcontext *ctx,
> 			 const struct gl_client_array *inputs[],
> 			 GLint count,
> 			 struct gl_buffer_object **bo,
> 			 GLuint *nr_bo )
> {
>     ...
>     for (i = 0; i < VERT_ATTRIB_MAX; i++) {
>        const void *ptr;
> 
>        if (inputs[i]->BufferObj->Name) {
> 	 if (!inputs[i]->BufferObj->Pointer) {
> 	    ...
> 	
> 	    printf("i : %i\n", i);
> 	    printf("name: %i\n", inputs[i]->BufferObj->Name);
> 	    assert(inputs[i]->BufferObj->Pointer);
> 	 }
>     ...
> }
> 
> On successful runs it looks like:
> i : 0
> name: 1
> i : 0
> name: 1
> i : 31
> name: 1
> 
> However when the assertion fails, the output is:
> i : 0
> name: 1
> i : 31
> name: 10999
> 
> Not sure that's very helpful, perhaps you can point me in the right 
> direction for producing more relevant debug output.

I haven't seen that one before.  Do you happen to have a small test 
program that I could try here?  I think I've got a 64-bit Linux install 
here somewhere...

You might also try running with valgrind to see if it finds anything.

-Brian

[Mesa3d-users] tnl/t_draw.c:205: bind_inputs: Assertion `inputs[i]->BufferObj->Pointer' failed.

[Utkarsh A. <utk...@ki...>]

Hi Brian,

I am trying to come up with a small test case that reproduces this issue 
that we are having with ParaView using Mesa 7.1 (as well as git-Mesa) on 
a 64 bit debian box.

The assertion fails following repeated creation/deletion of display 
lists (ofcourse when display lists are not used, everything is peachy).

For debugging purposes I put a printf as follows in tnl/t_draw.c:

static void bind_inputs( GLcontext *ctx,
			 const struct gl_client_array *inputs[],
			 GLint count,
			 struct gl_buffer_object **bo,
			 GLuint *nr_bo )
{
    ...
    for (i = 0; i < VERT_ATTRIB_MAX; i++) {
       const void *ptr;

       if (inputs[i]->BufferObj->Name) {
	 if (!inputs[i]->BufferObj->Pointer) {
	    ...
	
	    printf("i : %i\n", i);
	    printf("name: %i\n", inputs[i]->BufferObj->Name);
	    assert(inputs[i]->BufferObj->Pointer);
	 }
    ...
}

On successful runs it looks like:
i : 0
name: 1
i : 0
name: 1
i : 31
name: 1

However when the assertion fails, the output is:
i : 0
name: 1
i : 31
name: 10999

Not sure that's very helpful, perhaps you can point me in the right 
direction for producing more relevant debug output.

Thanks,
Utkarsh

[Mesa3d-users] Glu Nurbs Error when trimming a nurb surface

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

Hi Brian,
Thank you for help, I have done what you have suggested.
I obtianed this error :

s difference 0.250000
Assertion failed: head == NULL, file
..\..\..\..\src\glu\sgi\libnurbs\internals\
bin.cc, line 58

I disabled this last assertion, I obtained this one


Run-Time Check Failure #0 - The value of ESP was not properly saved across a
function call.  This is usually a result of calling a function declared with
one calling convention with a function pointer declared with a different
calling convention.


//file : nurbstess.cc - line 308
    do_freeall( );
    resetObjects();
}


I think it could be precision error between the engine and glu (s difference
0.250000). I am using GLfloat to declare cltpoints and knots. Is this
possible?

Regards

Re: [Mesa3d-users] Glu Nurbs Error when trimming a nurb surface

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

n9ine nvidia engine wrote:
> Hi all;
> 
> I a m programming a nurb viewer using a 3d engine (written in c++). I
> am using glu api to create the nurb and then tissalate it.
> 
> I have got this error  when I try to trim the surface. The same code
> work fine when I use Opengl to draw the nurb. And I succeded to view a
> non trimmed surface with the engine. But when I trimm it :( this is
> What i got :
> 
> checkjarc: geometric linkage screwed up 3
>         PWLARC NP: 2 FL: 1
>                 VERTEX 0.250000 0.500000
>                 VERTEX 0.000000 0.000000
>         PWLARC NP: 2 FL: 1
>                 VERTEX 0.250000 0.250000
>                 VERTEX 0.000000 0.000000
> Assertion failed: bin.firstarc()->check() != 0, file ..\..\..\..\src
> \glu\sgi\lib
> nurbs\internals\subdivider.cc, line 658
> 
> Can some gentil man help me.
> 

The nurbs tessellator/trimmer is fairly complex code so it's hard to say 
what's really happening.  A few things you could try though:

1. It looks like there's some debug code in the Arc::check() function in 
arc.cc that, if enabled, might give some clues.

2. Try disabling the failing assertion, or just return from the function 
if it fails.

-Brian

[Mesa3d-users] Glu Nurbs Error when trimming a nurb surface

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

Hi all;

I a m programming a nurb viewer using a 3d engine (written in c++). I
am using glu api to create the nurb and then tissalate it.

I have got this error  when I try to trim the surface. The same code
work fine when I use Opengl to draw the nurb. And I succeded to view a
non trimmed surface with the engine. But when I trimm it :( this is
What i got :

checkjarc: geometric linkage screwed up 3
        PWLARC NP: 2 FL: 1
                VERTEX 0.250000 0.500000
                VERTEX 0.000000 0.000000
        PWLARC NP: 2 FL: 1
                VERTEX 0.250000 0.250000
                VERTEX 0.000000 0.000000
Assertion failed: bin.firstarc()->check() != 0, file ..\..\..\..\src
\glu\sgi\lib
nurbs\internals\subdivider.cc, line 658

Can some gentil man help me.
kind regards

Re: [Mesa3d-users] Heap Corruption?

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

sdc395 wrote:
> 
> sdc395 wrote:
>> Hello list
>>
>> I appear to be suffering heap corruption caused by creating, applying,
>> deleting and then recreating a Mesa3D context within a Windows
>> application.
>>
>> To demonstrate, I've built the latest version of Mesa3D (7.0.3) using
>> Visual Studio 2005 and used the libraries with a sample application I
>> downloaded from  http://www.nullterminator.net/opengl32.html here .  I
>> moved the calls to EnableOpenGL() and DisableOpenGL() (see the sample
>> code) to reside within the rendering loop and BANG!
>>
>> I realise this is bad practice but surely it should work regardless.  I my
>> real application, I create and destroy contexts alongside CViews of the
>> application's model.  This works fine using Windows' own OpenGL
>> implementation but dies as soon as I switch to using Mesa3D.
>>
> Just thought I'd follow this up to let everyone know that things appear
> unchanged for 7.0.4 and 7.1.  I've spent as much time as I dare trying to
> pin the problem down but, since no one seems to be interested in fixing it
> (or even trying to reproduce it), we're simply going to have to abandon
> Mesa3D.  It's supposed to be our emergency rendering option but it's more
> trouble than it's worth.

You might get a better audience on the mesa3d-dev list.

Can you provide a stack trace or any other info from the crash?

Can you try a memory checker like Purify (or equivalent)?  You might be 
able to get a trial version of Purify.

You could also try a few things like disabling the rendering code in the 
loop to see if that's involved.

-Brian

Re: [Mesa3d-users] Heap Corruption?

[sdc395 <mes...@de...>]

sdc395 wrote:
> 
> Hello list
> 
> I appear to be suffering heap corruption caused by creating, applying,
> deleting and then recreating a Mesa3D context within a Windows
> application.
> 
> To demonstrate, I've built the latest version of Mesa3D (7.0.3) using
> Visual Studio 2005 and used the libraries with a sample application I
> downloaded from  http://www.nullterminator.net/opengl32.html here .  I
> moved the calls to EnableOpenGL() and DisableOpenGL() (see the sample
> code) to reside within the rendering loop and BANG!
> 
> I realise this is bad practice but surely it should work regardless.  I my
> real application, I create and destroy contexts alongside CViews of the
> application's model.  This works fine using Windows' own OpenGL
> implementation but dies as soon as I switch to using Mesa3D.
> 
Just thought I'd follow this up to let everyone know that things appear
unchanged for 7.0.4 and 7.1.  I've spent as much time as I dare trying to
pin the problem down but, since no one seems to be interested in fixing it
(or even trying to reproduce it), we're simply going to have to abandon
Mesa3D.  It's supposed to be our emergency rendering option but it's more
trouble than it's worth.
-- 
View this message in context: http://www.nabble.com/Heap-Corruption--tp16558747p19220385.html
Sent from the mesa3d-users mailing list archive at Nabble.com.

Re: [Mesa3d-users] Embedding Mesa3D

[<us...@mo...>]

09.07.2008  23:56           755 115 libGLU.so.1
09.07.2008  23:56         3 002 079 libOSMesa.so.6

I use it for TomTom Navigation system, ARM9 Samsung S3CXX falimy. It has not 
3d whatsoever...

----- Original Message ----- 
From: "Rob Emanuele" <rj...@cr...>
To: <us...@mo...>
Cc: <mes...@li...>
Sent: Thursday, August 28, 2008 8:25 PM
Subject: Re: [Mesa3d-users] Embedding Mesa3D


> That's some good news.  On the ARM, what is the code size for the
> library?  I'm not too worried about rendering time as the processor is
> fast but I may have limited code space.
>
> Thanks!
> --Rob
>
> On Thu, Aug 28, 2008 at 11:11 AM,  <us...@mo...> wrote:
>> I have it ported to ARM. Had to do some tricks to compile but now it's 
>> OK.
>> I did not managed to reduce the code size, only little bit memory 
>> footprint
>> by playing with settings in .h files
>> However, my ARM does not have floating point and Mesa is more or less
>> useless because it's very slow.
>> But it works and it's fine for non-realtime rendering and all mesa 
>> exmaples
>> work also
>> However again, I tried to use it with some non-real-time apps like chess
>> program but it was not rendering correctly on my device - wrong colors,
>> ureadable fonts, etc.
>>
>> ----- Original Message ----- From: "Rob Emanuele" <rj...@cr...>
>> To: <mes...@li...>
>> Sent: Thursday, August 28, 2008 7:54 PM
>> Subject: [Mesa3d-users] Embedding Mesa3D
>>
>>
>>> Has anyone done anything with embedding Mesa3D into a mobile device?
>>> We're looking to see if its feasible and how small we can get it.
>>>
>>> Thanks,
>>>
>>> Rob
>>>
>>> -------------------------------------------------------------------------
>>> 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] Embedding Mesa3D

[Rob E. <rj...@cr...>]

The ARM9 is a possibility, but I have been looking at the ARM GPUs and
Mali Graphics stack.  The information is limited on that though as is
finding someone who has implemented it.

Mesa3d could be an excellent solution for me if the code size can be
reasonable.

For us...@mo..., I have read that using EABI instead of OABI as
you compile to your target, can increase the speed of your floating
point operations.

On Thu, Aug 28, 2008 at 11:41 AM, Alessandro Borges
<ale...@gm...> wrote:
> Hi
>
> I'm curious about your project. Is it for Symbian ? ARM-9 ? ARM-11 ?
>
> For 3D on mobile devices you can also consider :
> * target ARM processors supporting OpenGL|ES. Some ARM has OpenGL|ES HW
> acceleration;
> http://www.arm.com/products/multimedia/graphics/index.html
>
> * There are some  Java 3D API for mobiles as M3G JSR-184, Moscot Capsule,
> OpenGL|ES JSR-239;
> Nearly 95% of mobile devices made after 2004 are ready to run above APIs.
> i.e. "billions" .
>
>
> Alessandro
>
>
>
> -------------------------------------------------------------------------
> 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] Embedding Mesa3D

[Alessandro B. <ale...@gm...>]

Hi

I'm curious about your project. Is it for Symbian ? ARM-9 ? ARM-11 ?

For 3D on mobile devices you can also consider :
* target ARM processors supporting OpenGL|ES. Some ARM has OpenGL|ES HW
acceleration;
http://www.arm.com/products/multimedia/graphics/index.html

* There are some  Java 3D API for mobiles as M3G JSR-184, Moscot Capsule,
OpenGL|ES JSR-239;
Nearly 95% of mobile devices made after 2004 are ready to run above APIs.
i.e. "billions" .


Alessandro

Re: [Mesa3d-users] Embedding Mesa3D

[Rob E. <rj...@cr...>]

That's some good news.  On the ARM, what is the code size for the
library?  I'm not too worried about rendering time as the processor is
fast but I may have limited code space.

Thanks!
--Rob

On Thu, Aug 28, 2008 at 11:11 AM,  <us...@mo...> wrote:
> I have it ported to ARM. Had to do some tricks to compile but now it's OK.
> I did not managed to reduce the code size, only little bit memory footprint
> by playing with settings in .h files
> However, my ARM does not have floating point and Mesa is more or less
> useless because it's very slow.
> But it works and it's fine for non-realtime rendering and all mesa exmaples
> work also
> However again, I tried to use it with some non-real-time apps like chess
> program but it was not rendering correctly on my device - wrong colors,
> ureadable fonts, etc.
>
> ----- Original Message ----- From: "Rob Emanuele" <rj...@cr...>
> To: <mes...@li...>
> Sent: Thursday, August 28, 2008 7:54 PM
> Subject: [Mesa3d-users] Embedding Mesa3D
>
>
>> Has anyone done anything with embedding Mesa3D into a mobile device?
>> We're looking to see if its feasible and how small we can get it.
>>
>> Thanks,
>>
>> Rob
>>
>> -------------------------------------------------------------------------
>> 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] Embedding Mesa3D

[<us...@mo...>]

I have it ported to ARM. Had to do some tricks to compile but now it's OK.
I did not managed to reduce the code size, only little bit memory footprint 
by playing with settings in .h files
However, my ARM does not have floating point and Mesa is more or less 
useless because it's very slow.
But it works and it's fine for non-realtime rendering and all mesa exmaples 
work also
However again, I tried to use it with some non-real-time apps like chess 
program but it was not rendering correctly on my device - wrong colors, 
ureadable fonts, etc.

----- Original Message ----- 
From: "Rob Emanuele" <rj...@cr...>
To: <mes...@li...>
Sent: Thursday, August 28, 2008 7:54 PM
Subject: [Mesa3d-users] Embedding Mesa3D


> Has anyone done anything with embedding Mesa3D into a mobile device?
> We're looking to see if its feasible and how small we can get it.
>
> Thanks,
>
> Rob
>
> -------------------------------------------------------------------------
> 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] Embedding Mesa3D

[Rob E. <rj...@cr...>]

Has anyone done anything with embedding Mesa3D into a mobile device?
We're looking to see if its feasible and how small we can get it.

Thanks,

Rob

[Mesa3d-users] Mesa 7.1 released

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

Mesa 7.1 can be downloaded from 
http://sourceforge.net/project/showfiles.php?group_id=3

This is a new development release.  Bugs found/fixed in 7.1 will be 
incorporated in the 7.2 release.

Thanks to everyone that helped with testing, etc.

-Brian

Re: [Mesa3d-users] main/renderbuffer.c:2153: _mesa_reference_renderbuffer: Assertion [...] failed

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

Kaido Kärner wrote:
>> Could someone skilled with gdb do the following?  We might get to the
>> bottom of this.
>>
>> 1. Put a breakpoint on viaDeleteRenderbuffer() and make note of the
>> value of rb each time it's called, and get a stack trace each time.
>>
>> 2. When the assertion in renderbuffer.c fails, print 'oldRb' and
>> provide a stack trace.
> 
> The problem is, that the buffers are allocated in the context structure, not the drawable.

Yes, that's the root problem but would take more effort to fix.  I'm 
just looking for a work-around for now (without hacking core Mesa).


> And if the context is freed before the drawable - which has pointers to buffers - the 
> crash is inevitable, as viaDestroyContext frees the memory which holds the buffers.

We may be able to "fix" that with a tweak to the refcounting.


> I can do any additional debugging, if needed, tomorrow.

Please do.

-Brian

Re: [Mesa3d-users] main/renderbuffer.c:2153: _mesa_reference_renderbuffer: Assertion [...] failed

[Kaido K. <ka...@tr...>]

> Could someone skilled with gdb do the following?  We might get to the
> bottom of this.
> 
> 1. Put a breakpoint on viaDeleteRenderbuffer() and make note of the
> value of rb each time it's called, and get a stack trace each time.
> 
> 2. When the assertion in renderbuffer.c fails, print 'oldRb' and
> provide a stack trace.

The problem is, that the buffers are allocated in the context structure, not the drawable.
And if the context is freed before the drawable - which has pointers to buffers - the 
crash is inevitable, as viaDestroyContext frees the memory which holds the buffers.

I can do any additional debugging, if needed, tomorrow.

kaido

Re: [Mesa3d-users] main/renderbuffer.c:2153: _mesa_reference_renderbuffer: Assertion [...] failed

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

Could someone skilled with gdb do the following?  We might get to the 
bottom of this.

1. Put a breakpoint on viaDeleteRenderbuffer() and make note of the 
value of rb each time it's called, and get a stack trace each time.

2. When the assertion in renderbuffer.c fails, print 'oldRb' and provide 
a stack trace.

-Brian


Kyle Hamilton wrote:
> This might end up causing a memory leak if driverPrivate isn't freed
> ahead of time.  If it is, then the place where it's freed should
> actually do the re-setting of it to NULL.
> 
> -Kyle H
> 
> On Tue, Aug 26, 2008 at 12:39 PM, Kaido Kärner <ka...@tr...> wrote:
>> Hi!
>>
>> to quick-fix the assert I used the following approach:
>>
>> first, in via_context.c in viaDestroyContent() mark the buffer as NULL just
>> before the vmesa is freed.
>>
>>  __DRIdrawablePrivate *const drawable = vmesa->driDrawable;
>>   if (drawable) {
>>     drawable->driverPrivate = NULL;
>>   }
>>
>> second, in via_screen.c in viaDestroyBuffer() check if
>> driDrawPriv->driverPrivate is not NULL before acessing it.
>>
>> works for me.
>>
>>
>> regards,
>> kaido
>>
>>
>> -------------------------------------------------------------------------
>> 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
>>
>>
> -------------------------------------------------------------------------
> 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] main/renderbuffer.c:2153: _mesa_reference_renderbuffer: Assertion [...] failed

[Kyle H. <aer...@gm...>]

This might end up causing a memory leak if driverPrivate isn't freed
ahead of time.  If it is, then the place where it's freed should
actually do the re-setting of it to NULL.

-Kyle H

On Tue, Aug 26, 2008 at 12:39 PM, Kaido Kärner <ka...@tr...> wrote:
> Hi!
>
> to quick-fix the assert I used the following approach:
>
> first, in via_context.c in viaDestroyContent() mark the buffer as NULL just
> before the vmesa is freed.
>
>  __DRIdrawablePrivate *const drawable = vmesa->driDrawable;
>   if (drawable) {
>     drawable->driverPrivate = NULL;
>   }
>
> second, in via_screen.c in viaDestroyBuffer() check if
> driDrawPriv->driverPrivate is not NULL before acessing it.
>
> works for me.
>
>
> regards,
> kaido
>
>
> -------------------------------------------------------------------------
> 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] main/renderbuffer.c:2153: _mesa_reference_renderbuffer: Assertion [...] failed

[Kaido K. <ka...@tr...>]

Hi!

to quick-fix the assert I used the following approach:

first, in via_context.c in viaDestroyContent() mark the buffer as NULL just before the vmesa is freed.

 __DRIdrawablePrivate *const drawable = vmesa->driDrawable; 
  if (drawable) { 
    drawable->driverPrivate = NULL; 
  }

second, in via_screen.c in viaDestroyBuffer() check if driDrawPriv->driverPrivate is not NULL before acessing it.

works for me.


regards,
kaido

Re: [Mesa3d-users] Compiling problems

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

Enigma wrote:
> Hi to all!
> I've downloaded the Mesa library (version 7.0.4). I've extract the 
> archive and then I've open "Mesa-7.0.4\windows\VC8\mesa\mesa.sln" with 
> Visual C++ Express Edition 2008.
> After the project conversion, I try to compile "mesa" in release mode. 
> It's finish correctly with no errors.
> Now I try to compile "gdi". I obtain this error:
> 1>------ Inizio compilazione: Progetto: gdi, Configurazione: Debug Win32 
> ------
> 1>Collegamento in corso...
> 1>LINK : fatal error LNK1181: impossibile aprire il file di input 'mesa.lib'
> 1>Il log di compilazione è stato salvato in 'file://c:\Documents and 
> Settings\Enigma\Desktop\Mesa-7.0.4\windows\VC8\mesa\gdi\Debug\BuildLog.htm'
> 1>gdi - 1 errore/i, 0 avviso/i
> ========== Compilazione: 0 completate, 1 non riuscite, 0 aggiornate, 0 
> ignorate ==========
> 
> And if I try to compile "osmesa", I obtain this error:
> 
> 1>------ Inizio compilazione: Progetto: osmesa, Configurazione: Release Win32 ------
> 1>Collegamento in corso...
> 1>   Creazione della libreria .\Release/OSMESA32.lib e dell'oggetto .\Release/OSMESA32.exp in corso...
> 1>driverfuncs.obj : error LNK2019: riferimento al simbolo esterno __mesa_get_uniformiv non risolto nella funzione __mesa_init_glsl_driver_functions
> 1>Release/OSMESA32.DLL : fatal error LNK1120: 1 esterni non risolti
> 1>Il log di compilazione è stato salvato in 'file://c:\Documents and Settings\Enigma\Desktop\MesaLib-7.0.4\Mesa-7.0.4\windows\VC8\mesa\osmesa\Release\BuildLog.htm'
> 1>osmesa - 2 errore/i, 0 avviso/i
> ========== Compilazione: 0 completate, 1 non riuscite, 2 aggiornate, 0 ignorate ==========
> 
> I don't understand where is the problem...
> Thanks!

Looks like a missing symbol in the src/mesa/drivers/windows/gdi/mesa.def 
  file.  Here's the patch:

diff --git a/src/mesa/drivers/windows/gdi/mesa.def 
b/src/mesa/drivers/windows/gd
index c525945..42e813b 100644
--- a/src/mesa/drivers/windows/gdi/mesa.def
+++ b/src/mesa/drivers/windows/gdi/mesa.def
@@ -917,6 +917,7 @@ EXPORTS
         _mesa_get_shader_source
         _mesa_get_teximage
         _mesa_get_uniformfv
+       _mesa_get_uniformiv
         _mesa_get_uniform_location
         _mesa_init_driver_functions
         _mesa_init_renderbuffer

Let me know if other symbols are needed...

-Brian