chromium-dev — For developers of the Chromium framework or SPU's

Re: [Chromium-dev] Possible problem in crStateTransformDiff (state_transform.c)

[<ma...@co...>]

Brian,

That's funny - I just sent out my own change to diffapi!

The version you sent seems to work just fine - so I'd say check it in!

Thanks,
Jon

Quoting Brian Paul <bri...@tu...>:

> Jon,
>
> Try the attached tilesort/diffapi.py file.  I'm not sure why
> ActiveTexture and TexEnviv are special-cased in that script (maybe it
> was a debugging thing).
>
> If this works, I'll check in the change.
>
> -Brian
>

[Chromium-dev] Suggested changes to pixel.c and tilesort's diffapi.py

[<ma...@co...>]

Hi all,

(I'm resending this message with smaller attachments.)

Here are updated versions of util/pixel.c and diffapi.py from the tilesort spu
which include work-arounds/fixes for release builds under Win32 (with Visual
Studio .NET 2003).

In pixel.c I've converted the outer switch/case statements into if-else
blocks. The old code is there in an ifdef if anyone would like to compare the
two versions.

For diffapi.py I removed the nop function and replaced it with more fleshed
out no-ops for the two functions that nop was being assigned to -
ActiveTextureARB and TexEnviv. (Can anyone explain why those are no-ops? There
are still many parts of Cr that are mysterious to me!)


Let me know what you think (and if they work under other platforms...!),
Jon

RE: [Chromium-dev] Possible problem in crStateTransformDiff (state_transform.c)

[<ma...@co...>]

Hi Brian,

Yes we're using VS .Net 2003.

As a side note - I had to change some of the nested case statements in pixel.c
into if-elses to get that to compile on a human time scale. I'll send a copy
when I get back to my dev box (if anyone's interested).

More importantly... I found the problem today!

It stems from diff_api.ActiveTextureARB pointing to a no-op function. I don't
have all the code in front of me right now, but the quick fix was to manually
change tilesortspu_diffapi.c such that the ActiveTextureARB function has the
right calling convention and args:

static void nop(void)
{
}

static void TILESORTSPU_APIENTRY tilesortspuDiffActiveTextureARB( GLenum
textureUnit ){

        return;
}

void tilesortspuCreateDiffAPI( void )
{
        SPUDispatchTable diff;

        crSPUInitDispatchTable(&diff);

        /* Note: state differencing should never involve calling a "glGet"
         * function.  So we set those pointers to NULL.
         */

        diff.Accum = tilesort_spu.swap ? crPackAccumSWAP : crPackAccum;
        /*diff.ActiveTextureARB = (ActiveTextureARBFunc_t) nop;*/
        diff.ActiveTextureARB = tilesortspuDiffActiveTextureARB;

...

The optimizer must have taken the "nop" to the extreme - it probably optimized
it to nothing - which probably meant it wasn't cleaning up the stack properly...

When I get a chance, I'll take a look at the script that generates
tilesortspu_diff.c and put the fix in there.

The good news is that everything else seems to be working OK with optimizations
on! So I think the hard part is over! In general though, we'll have to be on
the lookout for more nop functions like that one.

Thanks,
Jon



Quoting "Wylie, Brian" <bn...@sa...>:

> Just an observation. If your compiling with Visual Studio .Net 2003, we
> have had some seriously dorky stuff happen with that optimizer. So just
> an FYI. :)
>
> Brian Wylie - Org 9227
> Sandia National Laboratories
> MS 0822 - Building 880/A1-J
> (505)844-2238 FAX(505)845-0833
>      ____                  _    __
>     / __ \____  _________ | |  / (_)__ _      __
>    / /_/ / __ `/ ___/ __ `/ | / / / _ \ | /| / /
>   / ____/ /_/ / /  / /_/ /| |/ / /  __/ |/ |/ /
>  /_/    \__,_/_/   \__,_/ |___/_/\___/|__/|__/
>
>                                     Unleash the Beast
>
>

RE: [Chromium-dev] Possible problem in crStateTransformDiff ( state_transform.c)

[Wylie, B. <bn...@sa...>]

Just an observation. If your compiling with Visual Studio .Net 2003, we
have had some seriously dorky stuff happen with that optimizer. So just
an FYI. :)

Brian Wylie - Org 9227
Sandia National Laboratories
MS 0822 - Building 880/A1-J
(505)844-2238 FAX(505)845-0833                      =20
     ____                  _    __
    / __ \____  _________ | |  / (_)__ _      __=20
   / /_/ / __ `/ ___/ __ `/ | / / / _ \ | /| / /
  / ____/ /_/ / /  / /_/ /| |/ / /  __/ |/ |/ /
 /_/    \__,_/_/   \__,_/ |___/_/\___/|__/|__/

                                    Unleash the Beast
=20

> -----Original Message-----
> From: chr...@li...=20
> [mailto:chr...@li...] On Behalf=20
> Of ma...@co...
> Sent: Sunday, July 24, 2005 8:27 PM
> To: chr...@li...
> Subject: [Chromium-dev] Possible problem in=20
> crStateTransformDiff ( state_transform.c)
>=20
> Hi all,
>=20
> I'm trying to track down a bug/crash that only is appearing=20
> under RELEASE builds on Win32. It seems that the release=20
> build may be exposing a bug (I don't suspect a bad=20
> optimization here... but it could be...)
>=20
> As far as I've been able to trace things, the problem area=20
> starts around line 1330 or so in state_transform.c. It's a=20
> loop that looks like it's comparing texture matrix stacks,=20
> but to be honest, its purpose is a bit beyond me!
>=20
> Could someone who's more familiar with the state tracking=20
> mechanisms take a look at that loop and see if there isn't=20
> something fishy going on?
>=20
> Thanks,
> Jon
>=20
> For reference the code from that section is as follows:
>=20
> for (j =3D 0 ; j < maxTextureUnits; j++)
> {
> 	if (from->textureStack[j].depth > to->textureStack[j].depth)
> 	{
> 		if (textureFrom->curTextureUnit !=3D j) {
> 			diff_api.ActiveTextureARB( j +=20
> GL_TEXTURE0_ARB );
> 			textureFrom->curTextureUnit =3D j;
> 		}
> 		for (i =3D to->textureStack[j].depth; i <=20
> from->textureStack [j].depth; i++)
> 		{
> 			diff_api.PopMatrix();
> 		}
>=20
> 		from->textureStack[j].depth =3D to->textureStack[j].depth;
> 	}
>=20
> 	for (i =3D from->textureStack[j].depth; i <=3D=20
> to->textureStack[j].depth;
> i++)
> 	{
> 		if (textureFrom->curTextureUnit !=3D j) {
> 			diff_api.ActiveTextureARB( j +=20
> GL_TEXTURE0_ARB );
> 			textureFrom->curTextureUnit =3D j;
> 		}
> 		LOADMATRIX(to->textureStack[j].stack + i);
> 		from->textureStack[j].stack[i] =3D=20
> to->textureStack[j].stack[i];
>=20
> 		/* Don't want to push on the current matrix */
> 		if (i !=3D to->textureStack[j].depth)
> 			diff_api.PushMatrix();
> 	}
> 	from->textureStack[j].depth =3D to->textureStack[j].depth;
> 	from->textureStack[j].top =3D from->textureStack[j].stack + from-
> >textureStack[j].depth;
> }
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration=20
> Strategies from IBM. Find simple to follow Roadmaps,=20
> straightforward articles, informative Webcasts and more! Get=20
> everything you need to get up to speed, fast.=20
> http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclick
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev
>=20
>=20

[Chromium-dev] Possible problem in crStateTransformDiff (state_transform.c)

[<ma...@co...>]

Hi all,

I'm trying to track down a bug/crash that only is appearing under RELEASE
builds on Win32. It seems that the release build may be exposing a bug (I
don't suspect a bad optimization here... but it could be...)

As far as I've been able to trace things, the problem area starts around line
1330 or so in state_transform.c. It's a loop that looks like it's comparing
texture matrix stacks, but to be honest, its purpose is a bit beyond me!

Could someone who's more familiar with the state tracking mechanisms take a
look at that loop and see if there isn't something fishy going on?

Thanks,
Jon

For reference the code from that section is as follows:

for (j = 0 ; j < maxTextureUnits; j++)
{
	if (from->textureStack[j].depth > to->textureStack[j].depth)
	{
		if (textureFrom->curTextureUnit != j) {
			diff_api.ActiveTextureARB( j + GL_TEXTURE0_ARB );
			textureFrom->curTextureUnit = j;
		}
		for (i = to->textureStack[j].depth; i < from->textureStack
[j].depth; i++)
		{
			diff_api.PopMatrix();
		}

		from->textureStack[j].depth = to->textureStack[j].depth;
	}

	for (i = from->textureStack[j].depth; i <= to->textureStack[j].depth;
i++)
	{
		if (textureFrom->curTextureUnit != j) {
			diff_api.ActiveTextureARB( j + GL_TEXTURE0_ARB );
			textureFrom->curTextureUnit = j;
		}
		LOADMATRIX(to->textureStack[j].stack + i);
		from->textureStack[j].stack[i] = to->textureStack[j].stack[i];

		/* Don't want to push on the current matrix */
		if (i != to->textureStack[j].depth)
			diff_api.PushMatrix();
	}
	from->textureStack[j].depth = to->textureStack[j].depth;
	from->textureStack[j].top = from->textureStack[j].stack + from-
>textureStack[j].depth;
}

Re: [Chromium-dev] Using Chromium to extract a scenegraph

[Greg H. <hu...@gm...>]

I threw together a simple SPU that output each frame to a .ply file,  
but it was such a short program that I didn't really think to release  
it.  Basically I just multiplied each vertex by the modelview matrix,  
and then spat out the eye-space vertices to the file.  I maintained  
the connectivity of the triangles on the side, and dumped those after  
the triangles were done (required by the file format).  I think this  
was less than 100 lines of code in all (use the array spu to avoid  
having to deal with vertex arrays, and the state tracker to keep  
track of colors/normals/matrices).

Doing something hierarchical like a scene graph would certainly be  
useful, but I'm not aware of such a thing.

On Jul 15, 2005, at 8:19 PM, Brian Paul wrote:

> Daniel B. Faken wrote:
>
>> Hi All,
>>   Does anyone have pointers to such work/SPUs?
>>   For example, to convert a 'frame' of some OpenGL-program to  
>> 3DSMax format, .OBJ format, VRML, etc..
>>   It seems like a fairly obvious use, but I can't think of any  
>> work like this.. maybe there are some theoretic limitations?
>>   I suppose in the limit this is something like decompilation.
>>   There is of course file-output.  And the GLDB project which
>> can "capture" an object via a stream-query-language (it hasn't
>> released any software yet though - just the SIGGRAPH'05 paper at
>> http://www.cs.jhu.edu/~jab/gldb.pdf), and my own CRFreezer stuff.   
>> But none of these (AFAIK) attempt to deduce the structure of an  
>> entire scene from the GL stream.
>>   One could look e.g. for gl{Push,Pop}Matrix(), gl{Begin,End}(), gl 
>> {Push,Pop}Attrib(), .. as markers for subtrees in a scenegraph.
>> To extract objects one could look for coincident vertices (and/or  
>> use Chromium's bounding-boxes).
>>
>
> Sounds like that would be an interesting project.  I don't know of  
> anyone who's tried it.
>
> -Brian
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev
>
>

--
Greg Humphreys, Assistant Professor
Department of Computer Science, University of Virginia
http://www.cs.virginia.edu/~humper/

Re: [Chromium-dev] Using Chromium to extract a scenegraph

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

Daniel B. Faken wrote:
> Hi All,
> 
>   Does anyone have pointers to such work/SPUs?
>   For example, to convert a 'frame' of some OpenGL-program to 3DSMax 
> format, .OBJ format, VRML, etc..
> 
>   It seems like a fairly obvious use, but I can't think of any work like 
> this.. maybe there are some theoretic limitations?
>   I suppose in the limit this is something like decompilation.
> 
>   There is of course file-output.  And the GLDB project which
> can "capture" an object via a stream-query-language (it hasn't
> released any software yet though - just the SIGGRAPH'05 paper at
> http://www.cs.jhu.edu/~jab/gldb.pdf), and my own CRFreezer stuff.  But 
> none of these (AFAIK) attempt to deduce the structure of an entire scene 
> from the GL stream.
>   One could look e.g. for gl{Push,Pop}Matrix(), gl{Begin,End}(), 
> gl{Push,Pop}Attrib(), .. as markers for subtrees in a scenegraph.
> To extract objects one could look for coincident vertices (and/or use 
> Chromium's bounding-boxes).

Sounds like that would be an interesting project.  I don't know of 
anyone who's tried it.

-Brian

[Chromium-dev] Using Chromium to extract a scenegraph

[Daniel B. F. <fa...@ca...>]

Hi All,

  Does anyone have pointers to such work/SPUs?
  For example, to convert a 'frame' of some OpenGL-program to 3DSMax 
format, .OBJ format, VRML, etc..

  It seems like a fairly obvious use, but I can't think of any work like 
this.. maybe there are some theoretic limitations?
  I suppose in the limit this is something like decompilation.

  There is of course file-output.  And the GLDB project which
can "capture" an object via a stream-query-language (it hasn't
released any software yet though - just the SIGGRAPH'05 paper at
http://www.cs.jhu.edu/~jab/gldb.pdf), and my own CRFreezer stuff.  But 
none of these (AFAIK) attempt to deduce the structure of an entire scene 
from the GL stream.
  One could look e.g. for gl{Push,Pop}Matrix(), gl{Begin,End}(), 
gl{Push,Pop}Attrib(), .. as markers for subtrees in a scenegraph.
To extract objects one could look for coincident vertices (and/or use 
Chromium's bounding-boxes).

thanks,
Daniel Faken

Re: [Chromium-dev] A Chromium network layer for Portals 3?

[Michael H. <mho...@gr...>]

I don't think anyone has done this. 

MPI was started (SGI did the original work, Dale prodded it, as did I), 
but it became difficult to support MPI in the current NAL.  Portals 
shouldn't be too difficult if you can put together a connection based 
abstraction with send/recv/accept/connect, but I don't know if you will 
be able to use many of the fancy features of Portals.  It would 
definately be nice to port general interfaces (Portals, MPI, VIA, RDMA) 
instead of specific hardware (IB, Quadrics, Myrinet, etc)...

-Mike

Joel Welling wrote:

>Hi folks;
>  Has anyone looked at doing a Chromium network layer for the Portals 3 
>network programming interface?  I'm trying to figure out if this would be a 
>worthwhile thing to do.
>
>Thanks,
>-Joel
> we...@ps...
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
>July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
>core and dual graphics technology at this free one hour event hosted by HP,
>AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
>_______________________________________________
>Chromium-dev mailing list
>Chr...@li...
>https://lists.sourceforge.net/lists/listinfo/chromium-dev
>  
>

[Chromium-dev] A Chromium network layer for Portals 3?

[Joel W. <we...@st...>]

Hi folks;
  Has anyone looked at doing a Chromium network layer for the Portals 3 
network programming interface?  I'm trying to figure out if this would be a 
worthwhile thing to do.

Thanks,
-Joel
 we...@ps...

Re: [Chromium-dev] experimental crSPUChangeFunction ("not used at this time")

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

Daniel B. Faken wrote:
> Hi,
> 
> [I'm CCing this to chromium-dev]
> 
>   I noticed you [Brian P.] checked in the code apparently meant to go with 
> the DISPATCH_OFFSET_Xyz code.  Is there a reason crSPUChangeFunction() 
> isn't enabled?  Is it not portable to do this kind of offsetting?
>   I'm makeing a scripting extension, and it would be convenient to use the 
> offsets, but I don't want to if they're going away.

The idea was I wanted to improve the efficiency of the 
crSPUChangeInterface() function by providing a way to directly address 
positions in the dispatch table without having to do a search.

I just never had time to finish that project.  The offsets are 
auto-generated so they should be accurate/correct but there's no code 
in place that actually uses them at this time.

-Brian

[Chromium-dev] Re: pack_program_swap.c not in cr1.8

[<aac...@ad...>]

Oh.  Duh. 

Thanks.



---- Brian Paul <bri...@tu...> wrote: 
> aac...@ad... wrote:
> > Hi.
> > 
> > I have an older version of chromium 1.7 and noticed it contained
> > the file pack_program_swap.c and supported the call
> > crPackProgramStringARBSWAP.  I also have looked at the chromium
> > v1.8 code that is available and have noticed the
> > pack_program_swap.c file does not exist.  Is there a reason for the
> > file to not be included in the chromium v1.8?
> 
> That file is generated with a python script during compilation time. 
> I.e. if you run 'make', it'll get generated.  That's true of quite a 
> few source files in Chromium.
> 
> -Brian
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
> July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
> core and dual graphics technology at this free one hour event hosted by HP,
> AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev

Re: [Chromium-dev] pack_program_swap.c not in cr1.8

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

aac...@ad... wrote:
> Hi.
> 
> I have an older version of chromium 1.7 and noticed it contained
> the file pack_program_swap.c and supported the call
> crPackProgramStringARBSWAP.  I also have looked at the chromium
> v1.8 code that is available and have noticed the
> pack_program_swap.c file does not exist.  Is there a reason for the
> file to not be included in the chromium v1.8?

That file is generated with a python script during compilation time. 
I.e. if you run 'make', it'll get generated.  That's true of quite a 
few source files in Chromium.

-Brian

[Chromium-dev] pack_program_swap.c not in cr1.8

[<aac...@ad...>]

Hi.

I have an older version of chromium 1.7 and noticed it contained the file pack_program_swap.c and supported the call crPackProgramStringARBSWAP.  I also have looked at the chromium v1.8 code that is available and have noticed the pack_program_swap.c file does not exist.  Is there a reason for the file to not be included in the chromium v1.8?  


Thanks,
Alicia

[Chromium-dev] experimental crSPUChangeFunction ("not used at this time")

[Daniel B. F. <fa...@ca...>]

Hi,

[I'm CCing this to chromium-dev]

  I noticed you [Brian P.] checked in the code apparently meant to go with 
the DISPATCH_OFFSET_Xyz code.  Is there a reason crSPUChangeFunction() 
isn't enabled?  Is it not portable to do this kind of offsetting?
  I'm makeing a scripting extension, and it would be convenient to use the 
offsets, but I don't want to if they're going away.

thanks,
Daniel Faken

[Chromium-dev] Oak Ridge National Laboratory

[Sean A. <sea...@ll...>]

I wanted to let everyone on the Chromium development list know that I
will be transferring to Oak Ridge National Laboratory.  I've accepted a
position there as Visualization Task Leader and start next week.  I hope
to continue being involved with Chromium, as they will have a
significant for cluster visualization.

Eric Brugger will be serving as Visualization Project Leader here at
LLNL in an acting capacity.

Wish me luck!

-Sean

__
sea...@ll...
925-422-1648

Re: [Chromium-dev] Texture crashes being caused by pack_texture.crev 1.35

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

I agree=2E  Whoever calls crPackAlloc() should call crPackFree()=2E  I was=

hesitant about that though because of the buffered vs=2E non-buffered case=
s=2E=20
They're different code paths=2E  See the IS_BUFFERED() test in
crHugePacket()=2E  But it looks like crPackFree() does the same test so it=

should be safe to call it all the time=2E

I'd say go ahead and check in your patch=2E

-Brian


Original Message:
-----------------
From: Michael Houston mhouston@graphics=2Estanford=2Eedu
Date: Tue, 28 Jun 2005 12:53:30 -0700
To: brian=2Epaul@tungstengraphics=2Ecom, chromium-dev@lists=2Esourceforge=2E=
net
Subject: Re: [Chromium-dev] Texture crashes being caused by
pack_texture=2Ecrev 1=2E35


Actually, I think the other way around makes more sense, i=2Ee=2E the call=
er=20
allocates the packet, so I think they should have to free it as well=2E  I=
=20
have a patched tree that already does this=2E  Most of the functions that=20=

use HugePacket currently issue the free=2E=2E=2E

-Mike

brian=2Epaul@tungstengraphics=2Ecom wrote:

>Mike wrote:
>
> =20
>
>>I tracked things down to pack_texture=2Ec in the 1=2E35 change list whic=
h is=20
>>causing the texture crashes for me=2E  It looks like some of the additio=
ns=20
>>of crPackFree()'s are incorrect and freeing NULL pointers=2E=2E=2E  We n=
eed to=20
>>take a longer look at that change list and probably back it out for now=2E=

>>   =20
>>
>
>I think the proper fix is to simply remove the crPackFree() calls from
>those functions=2E  When crHugePacket() is called, we wind up in a SPU
>function like packspuHuge() or tilesortHuge() which call crPackFree()
>themselves=2E
>
>We should probably add a comment to crHugePacket() in pack_buffer=2Ec to
>indicate that the caller should _not_ call crPackFree() and that it's up =
to
>the SPU routine called via pc->SendHuge() to do so=2E
>
>-Brian
>
>
>--------------------------------------------------------------------
>mail2web - Check your email from the web at
>http://mail2web=2Ecom/ =2E
>
>
>
>
>-------------------------------------------------------
>SF=2ENet email is sponsored by: Discover Easy Linux Migration Strategies
>from IBM=2E Find simple to follow Roadmaps, straightforward articles,
>informative Webcasts and more! Get everything you need to get up to
>speed, fast=2E http://ads=2Eosdn=2Ecom/?ad_idt77&alloc_id=16492&op=3Dclic=
k
>_______________________________________________
>Chromium-dev mailing list
>Chromium-dev@lists=2Esourceforge=2Enet
>https://lists=2Esourceforge=2Enet/lists/listinfo/chromium-dev
> =20
>

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web=2Ecom/ =2E

Re: [Chromium-dev] Texture crashes being caused by pack_texture.c rev 1.35

[Michael H. <mho...@gr...>]

Actually, I think the other way around makes more sense, i.e. the caller 
allocates the packet, so I think they should have to free it as well.  I 
have a patched tree that already does this.  Most of the functions that 
use HugePacket currently issue the free...

-Mike

bri...@tu... wrote:

>Mike wrote:
>
>  
>
>>I tracked things down to pack_texture.c in the 1.35 change list which is 
>>causing the texture crashes for me.  It looks like some of the additions 
>>of crPackFree()'s are incorrect and freeing NULL pointers...  We need to 
>>take a longer look at that change list and probably back it out for now.
>>    
>>
>
>I think the proper fix is to simply remove the crPackFree() calls from
>those functions.  When crHugePacket() is called, we wind up in a SPU
>function like packspuHuge() or tilesortHuge() which call crPackFree()
>themselves.
>
>We should probably add a comment to crHugePacket() in pack_buffer.c to
>indicate that the caller should _not_ call crPackFree() and that it's up to
>the SPU routine called via pc->SendHuge() to do so.
>
>-Brian
>
>
>--------------------------------------------------------------------
>mail2web - Check your email from the web at
>http://mail2web.com/ .
>
>
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>from IBM. Find simple to follow Roadmaps, straightforward articles,
>informative Webcasts and more! Get everything you need to get up to
>speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
>_______________________________________________
>Chromium-dev mailing list
>Chr...@li...
>https://lists.sourceforge.net/lists/listinfo/chromium-dev
>  
>

RE: [Chromium-dev] Texture crashes being caused by pack_texture.c rev 1.35

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

Mike wrote:

> I tracked things down to pack_texture=2Ec in the 1=2E35 change list whic=
h is=20
> causing the texture crashes for me=2E  It looks like some of the additio=
ns=20
> of crPackFree()'s are incorrect and freeing NULL pointers=2E=2E=2E  We n=
eed to=20
> take a longer look at that change list and probably back it out for now=2E=


I think the proper fix is to simply remove the crPackFree() calls from
those functions=2E  When crHugePacket() is called, we wind up in a SPU
function like packspuHuge() or tilesortHuge() which call crPackFree()
themselves=2E

We should probably add a comment to crHugePacket() in pack_buffer=2Ec to
indicate that the caller should _not_ call crPackFree() and that it's up t=
o
the SPU routine called via pc->SendHuge() to do so=2E

-Brian


--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web=2Ecom/ =2E

Re: [Chromium-dev] Texture crashes being caused by pack_texture.c rev 1.35

[Michael H. <mho...@gr...>]

This is caused by a double free.  All current implementations of 
HugePacket free the buffer internally.  I'll argue this is a bad thing 
and that the function that allocates the packet should be the one to 
free it.

-Mike

Michael Houston wrote:

> I tracked things down to pack_texture.c in the 1.35 change list which 
> is causing the texture crashes for me.  It looks like some of the 
> additions of crPackFree()'s are incorrect and freeing NULL 
> pointers...  We need to take a longer look at that change list and 
> probably back it out for now.
>
> -Mike
>
> Nathan Jeffery wrote:
>
>>
>> Thankyou all for investigating the problems, and providing feedback.
>>
>> so the problem appears to be with my setup, i'll keep investigating.
>>
>> thanks again for all the support offered, will update on progress
>>
>> Regards
>>
>> Nathan
>>
>>
>>
>> On Fri, 24 Jun 2005, Michael Houston wrote:
>>
>>> 1.8 is okay as well...  The textures seem to be working there for 
>>> me.  I'm running quake3 in a window and not full screen.  Full 
>>> screen seems to have display issues.  Not sure what's going on 
>>> there, but I remember I always had problems with the full screen 
>>> mode running through Chromium (WireGL as well).
>>>
>>> The segfaults I'm seeing crept in somewhere between 1.8 and top of 
>>> tree.  It segfaults almost immediately when loading the splash 
>>> screen (texture).
>>>
>>> -Mike
>>>
>>> Michael Houston wrote:
>>>
>>>> CR-1.7 works just fine.
>>>>
>>>> -Mike
>>>>
>>>> Brian Paul wrote:
>>>>
>>>>> Michael Houston wrote:
>>>>>
>>>>>> The crash is being caused in the pixel packing routines.  There 
>>>>>> is nothing obvious at the moment, so I'm going to backtrack 
>>>>>> through revisions until I can track down the change list.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I made some changes in some pixel packing code a few weeks ago.  
>>>>> If you can tell me how to reproduce the problem with a small test 
>>>>> case, I can look into it (but perhaps not until next week).
>>>>>
>>>>> -Brian
>>>>>
>>>>>
>>>>> -------------------------------------------------------
>>>>> SF.Net email is sponsored by: Discover Easy Linux Migration 
>>>>> Strategies
>>>>> from IBM. Find simple to follow Roadmaps, straightforward articles,
>>>>> informative Webcasts and more! Get everything you need to get up to
>>>>> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>>>>> _______________________________________________
>>>>> Chromium-dev mailing list
>>>>> Chr...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/chromium-dev
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>>>> from IBM. Find simple to follow Roadmaps, straightforward articles,
>>>> informative Webcasts and more! Get everything you need to get up to
>>>> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>>>> _______________________________________________
>>>> Chromium-dev mailing list
>>>> Chr...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/chromium-dev
>>>
>>>
>>>
>>
>>
>> -------------------------------------------------------
>> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>> from IBM. Find simple to follow Roadmaps, straightforward articles,
>> informative Webcasts and more! Get everything you need to get up to
>> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>> _______________________________________________
>> Chromium-users mailing list
>> Chr...@li...
>> https://lists.sourceforge.net/lists/listinfo/chromium-users
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev

[Chromium-dev] Texture crashes being caused by pack_texture.c rev 1.35

[Michael H. <mho...@gr...>]

I tracked things down to pack_texture.c in the 1.35 change list which is 
causing the texture crashes for me.  It looks like some of the additions 
of crPackFree()'s are incorrect and freeing NULL pointers...  We need to 
take a longer look at that change list and probably back it out for now.

-Mike

Nathan Jeffery wrote:

>
> Thankyou all for investigating the problems, and providing feedback.
>
> so the problem appears to be with my setup, i'll keep investigating.
>
> thanks again for all the support offered, will update on progress
>
> Regards
>
> Nathan
>
>
>
> On Fri, 24 Jun 2005, Michael Houston wrote:
>
>> 1.8 is okay as well...  The textures seem to be working there for 
>> me.  I'm running quake3 in a window and not full screen.  Full screen 
>> seems to have display issues.  Not sure what's going on there, but I 
>> remember I always had problems with the full screen mode running 
>> through Chromium (WireGL as well).
>>
>> The segfaults I'm seeing crept in somewhere between 1.8 and top of 
>> tree.  It segfaults almost immediately when loading the splash screen 
>> (texture).
>>
>> -Mike
>>
>> Michael Houston wrote:
>>
>>> CR-1.7 works just fine.
>>>
>>> -Mike
>>>
>>> Brian Paul wrote:
>>>
>>>> Michael Houston wrote:
>>>>
>>>>> The crash is being caused in the pixel packing routines.  There is 
>>>>> nothing obvious at the moment, so I'm going to backtrack through 
>>>>> revisions until I can track down the change list.
>>>>
>>>>
>>>>
>>>>
>>>> I made some changes in some pixel packing code a few weeks ago.  If 
>>>> you can tell me how to reproduce the problem with a small test 
>>>> case, I can look into it (but perhaps not until next week).
>>>>
>>>> -Brian
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>>>> from IBM. Find simple to follow Roadmaps, straightforward articles,
>>>> informative Webcasts and more! Get everything you need to get up to
>>>> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>>>> _______________________________________________
>>>> Chromium-dev mailing list
>>>> Chr...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/chromium-dev
>>>
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>>> from IBM. Find simple to follow Roadmaps, straightforward articles,
>>> informative Webcasts and more! Get everything you need to get up to
>>> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>>> _______________________________________________
>>> Chromium-dev mailing list
>>> Chr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/chromium-dev
>>
>>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Chromium-users mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-users

Re: [Chromium-dev] Re: [Chromium-users] quake3 niggle under linux

[Michael H. <mho...@gr...>]

1.8 is okay as well...  The textures seem to be working there for me.  
I'm running quake3 in a window and not full screen.  Full screen seems 
to have display issues.  Not sure what's going on there, but I remember 
I always had problems with the full screen mode running through Chromium 
(WireGL as well).

The segfaults I'm seeing crept in somewhere between 1.8 and top of 
tree.  It segfaults almost immediately when loading the splash screen 
(texture).

-Mike

Michael Houston wrote:

> CR-1.7 works just fine.
>
> -Mike
>
> Brian Paul wrote:
>
>> Michael Houston wrote:
>>
>>> The crash is being caused in the pixel packing routines.  There is 
>>> nothing obvious at the moment, so I'm going to backtrack through 
>>> revisions until I can track down the change list.
>>
>>
>>
>> I made some changes in some pixel packing code a few weeks ago.  If 
>> you can tell me how to reproduce the problem with a small test case, 
>> I can look into it (but perhaps not until next week).
>>
>> -Brian
>>
>>
>> -------------------------------------------------------
>> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>> from IBM. Find simple to follow Roadmaps, straightforward articles,
>> informative Webcasts and more! Get everything you need to get up to
>> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>> _______________________________________________
>> Chromium-dev mailing list
>> Chr...@li...
>> https://lists.sourceforge.net/lists/listinfo/chromium-dev
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev

Re: [Chromium-dev] Re: [Chromium-users] quake3 niggle under linux

[Michael H. <mho...@gr...>]

CR-1.7 works just fine.

-Mike

Brian Paul wrote:

> Michael Houston wrote:
>
>> The crash is being caused in the pixel packing routines.  There is 
>> nothing obvious at the moment, so I'm going to backtrack through 
>> revisions until I can track down the change list.
>
>
> I made some changes in some pixel packing code a few weeks ago.  If 
> you can tell me how to reproduce the problem with a small test case, I 
> can look into it (but perhaps not until next week).
>
> -Brian
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev

Re: [Chromium-dev] Re: [Chromium-users] quake3 niggle under linux

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

Michael Houston wrote:
> The crash is being caused in the pixel packing routines.  There is 
> nothing obvious at the moment, so I'm going to backtrack through 
> revisions until I can track down the change list.

I made some changes in some pixel packing code a few weeks ago.  If 
you can tell me how to reproduce the problem with a small test case, I 
can look into it (but perhaps not until next week).

-Brian

[Chromium-dev] Re: [Chromium-users] quake3 niggle under linux

[Michael H. <mho...@gr...>]

The crash is being caused in the pixel packing routines.  There is 
nothing obvious at the moment, so I'm going to backtrack through 
revisions until I can track down the change list.

-Mike

Michael Houston wrote:

> Hrmm.  With top of tree, Quake is segfaulting, at least on my config 
> (RHEL4 an ATI 9800s with 8.14.13 drivers) running even through 
> crdemo.conf.  It runs fine alone.  Good fun, this might take awhile to 
> track down.
>
> -Mike
>
> Nathan Jeffery wrote:
>
>> Hi mike
>>
>> thanks for the response, i've tested all the bucket modes, but had no 
>> difference in effect. I havent tried disabling DLM yet, but will try 
>> that later today and report on the effect.
>>
>> Thankyou also for taking the timeout to investigate next week, will 
>> hopefully be able to provide more details before then
>>
>> BTW what are you still doing awake :-), I didn't expect a response 
>> until tomorrow
>>
>> Best regards
>>
>> Nathan
>>
>>
>> On Fri, 24 Jun 2005, Mike Houston wrote:
>>
>>> I haven't tested quake in awhile, but I remember I had issues if 
>>> Quake ran full screen, but no issues if I ran it in an X window. I 
>>> don't remember if I was having texturing issues or just performance 
>>> problems.  I'll try to find some time next week to take a look. 
>>> Although, this might be a new phenomenon as we've seen scattered 
>>> reports of various apps not displaying texture when running through 
>>> chromium.  Maybe a DLM bug has crept in?  What happens if you 
>>> disable DLM in the tilesort SPU? What about different bucket modes 
>>> like broadcast?
>>>
>>> -Mike
>>>
>>> Nathan Jeffery wrote:
>>>
>>>>
>>>> Hi
>>>>
>>>> i have another slight application niggle, and knowing alot of 
>>>> people have fully "tested" quake within chromium I'm certain that 
>>>> someone on this list will have the answer, Mike? :-) .
>>>>
>>>> When running quake3 on a linux box, with the output going to a 6 
>>>> channel render setup, the application runs fully  though there 
>>>> appears to be a distinct lack of textures being drawn. When running 
>>>> quake3 on a windows setup the scene is fully drawn.
>>>>
>>>> I've had the same problem with wildcat cards in the machines, and 
>>>> now fx3000g's.
>>>>
>>>> Is there a simple explanation as to why this might be the case 
>>>> under linux?
>>>>
>>>> thankyou in advance
>>>>
>>>> nathan
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>>>> from IBM. Find simple to follow Roadmaps, straightforward articles,
>>>> informative Webcasts and more! Get everything you need to get up to
>>>> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>>>> _______________________________________________
>>>> Chromium-users mailing list
>>>> Chr...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/chromium-users
>>>
>>>
>>>
>>>
>>
>>
>> -------------------------------------------------------
>> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>> from IBM. Find simple to follow Roadmaps, straightforward articles,
>> informative Webcasts and more! Get everything you need to get up to
>> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>> _______________________________________________
>> Chromium-users mailing list
>> Chr...@li...
>> https://lists.sourceforge.net/lists/listinfo/chromium-users
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Chromium-users mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-users