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

Re: [Chromium-dev] Re: VBO support in array SPU

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

Incidentally, Kevin Dale and I are having some issues with the way
renderspu_wgl.c is handling pixelformat calls as well -- in
particular, it's calling the wglSetPixelFormat call (instead of the
GDI SetPixelFormat call) even if the render spu is on the server.

My understanding was that we only called the wgl one directly if we
were loaded by the faker, to avoid an infinite loop.  Anyhow, I agree
that there's something fishy going on with wgl and pixelformats,
particularly when trying to run doom3.

On Thu, 17 Mar 2005 08:09:47 -0700, ma...@co...
<ma...@co...> wrote:
> Peter,
> 
> Re: hacking wgl.c - That's what we've been doing as well... for the moment,
> hacking it to make a particular app happy is what we've been doing as well.
> 
> What I've learned so far is that some apps like to see a software PixelFormat
> available before finding a HW accelerated pf. (SketchUp, an architectural
> design program is one app in particular.) So one thing we should do (at some
> point) is have Chromium expose a few PixelFormats so that apps that are
> designed to choose from a few have something to work with. We don't have to
> actually have chromium honor the differences in pixel format, of course...
> 
> We've also added a -notemp option to crappfaker so that it doesn't do the file
> copying to a temp directory. The code isn't clean enough right now to put back
> into the tree but it has helped us get a few apps going that were looking for
> files in particular relative locations.
> 
> Jon
> 
> ps. After rereading your message, the chromium render SPU is choosing
> PixelFormat 1...? Wierd. Hmmm, I haven't seen that problem. The app should be
> choosing PixelFormat 1 but the render SPU... Well I guess if you got it
> working I won't sweat it.
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&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/

[Chromium-dev] Chromium 1.8 release candidate

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

I've put a release candidate of Chromium 1.8 on the website at: 
http://chromium.sourceforge.net/beta/


I encourage everyone to download it and give it a try with your 
applications.  If everything checks out OK, I'm hoping to release 1.8 
next week.

-Brian

[Chromium-dev] Re: VBO support in array SPU

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

Peter,

Re: hacking wgl.c - That's what we've been doing as well... for the moment,
hacking it to make a particular app happy is what we've been doing as well.

What I've learned so far is that some apps like to see a software PixelFormat
available before finding a HW accelerated pf. (SketchUp, an architectural
design program is one app in particular.) So one thing we should do (at some
point) is have Chromium expose a few PixelFormats so that apps that are
designed to choose from a few have something to work with. We don't have to
actually have chromium honor the differences in pixel format, of course...

We've also added a -notemp option to crappfaker so that it doesn't do the file
copying to a temp directory. The code isn't clean enough right now to put back
into the tree but it has helped us get a few apps going that were looking for
files in particular relative locations.

Jon

ps. After rereading your message, the chromium render SPU is choosing
PixelFormat 1...? Wierd. Hmmm, I haven't seen that problem. The app should be
choosing PixelFormat 1 but the render SPU... Well I guess if you got it
working I won't sweat it.

Re: [Chromium-dev] VBO support in array SPU

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

Peter Djeu wrote:
> Sorry if you receive this email more than once.  I sent the original 
> version to the dev list about a week and a half ago (before I was a list 
> member), and that email still has not gone through the moderation 
> process, so I thought I'd resubmit.  -- Peter
> 
> Here's the original message:
> 
> Hi, I've been working on Chromium for some time now trying to get Doom 3 
> to run smoothly on it.  I added support for Vertex Buffer Objects 
> (VBO's) in the array SPU and wanted to submit my changes for review.  
> I've tested my modified version on a handful of applications that use 
> VBO's and normal vertex arrays, and it seems OK so far.  Here's what 
> I've included:
> 
> 1.  Attached, an archive containing patches to the array SPU that adds 
> support for regular VBO arays and for VBO element arrays.  A minor 
> (hopefully correct) fix is also included for the buffer object in the 
> state tracker.  This patch is diff'd with the cvs repository from Mar 1.
> 
> 2.  Below, a summary of what changes I made and where, for anyone 
> interested.
> 
> 3.  Below, questions I came across while putting together the patch.  If 
> anyone could answer these, I'd really appreciate it.
> 
>        Sincerely,
>        Peter Djeu
> 
> 
> <<< Summary >>>
> 
> 
> spu/array/arrayspu.c
>    - For the array SPU -- added offset calculations whenever a client 
> pointer has valid data in its VBO data ptr.  All uses are protected by a 
> #define guard so that the calculations are only done when the Vertex 
> Bufffer Object extension is enabled in cr_version.h.
> 
>    - Added missing gl function "IndexPointer" to pass along the color 
> index pointer to crStateIndexPointer().
> 
>    - Added gl functions to pass along all VBO interface calls to the 
> corresponding state tracker functions.
> 
>    - Added support in DrawElements() for Vertex Buffer Object element 
> arrays.
> 
> 
> spu/array/arrayspu_init.c
>    - For the array SPU -- on context initialization, if the Vertex 
> Buffer Object extension is enabled, set the buffer object's retainData 
> flag to GL_TRUE.
> 
> 
> state_tracker/state_bufferobject.c
>    - In the state tracker for VBO's -- when the null buffer is first 
> initialized in crStateBufferObjectInit(), its reference count is set to 
> 2. However, if the arrayBuffer and elementsBuffer both enter use, then 
> the nullBuffer reference count drops to 0, which causes an unnecessary 
> attempt to remove it from the hash table every time it is swapped out.  
> A fix is added to set the reference count to 3 on initialization (this 
> also makes more sense since the nullBuffer is being pointed to by 3 
> pointers anyway).
> 
>    - In crStateDeleteBuffersARB(), added a line to increment the 
> reference count of the nullBuffer when it replaces either arrayBuffer or 
> elementsBuffer. Otherwise, repeated swapping out of the nullBuffer 
> causes its reference count to wrap around, which is harmless although odd.
> 
> 
> <<< Questions >>>
> 
> Each question is preceded by the file it pertains to.
> 
> * state_tracker/state_bufferobject.c
> 
>    - Why are there ref counts within CRBufferObject's?  We can't free 
> the data associated with a buffer or remove it from the hashtable unless 
> the buffer is explicitly deleted by a DeleteBuffersARB call, so it seems 
> unusual what there is even logic present that frees a buffer when its 
> ref count drops to zero.  Also, because the buffer object initializer 
> starts the refcount at 1 and it immediately gets incremented to 2 
> (newObj->refCount++;) in crStateBindBufferARB(), no buffer object, 
> except for the nullBuffer, will ever get swapped out enough times for 
> its ref count to reach zero.

Buffer objects can potentially be shared between rendering contexts 
(like textures and display lists).  So in one context we might call 
glDeleteBuffersARB while the named buffer is still bound in another 
context.  We can't _really_ delete that buffer until the other 
contexts unbinds it.

That said, context sharing isn't fully implemented in Chromium so this 
case won't be hit as things are now.  Perhaps in the future...


> * spu/array/arrayspu.c
> 
>    - Is it customary to NOT put #define guards around entire GL 
> functions in a SPU, but to use them within the body of a parent function 
> call?  For example, use of the fog coordinate pointer is protected with 
> a "#ifdef CR_EXT_fog_coord" guard within arrayspu_ArrayElement(). 
> However, at the top level, the function arrayspu_FogCoordPointerEXT(), 
> at both its definition and listing in the SPU's named function table, do 
> not have this guard.  I have tried to follow the existing standard in 
> the current patch, but I can submit an update if using the missing 
> guards everywhere is more correct.

The #ifdef conventions for that are pretty loose.  The idea was that 
one could recompile Chromium without the code for a particular 
extension, if desired.  I don't think anyone's ever done that though. 
  So, the #ifdef stuff mostly just serves to highlight when code is 
needed for the sake of a particular extension.


> * opengl_stub/wgl.c
> 
>    - I had a lot of trouble (on Windows) trying to get Chromium to 
> choose the right pixel format for the render window (it was always 
> selecting Pixel Format 1, despite the visual attributes I was asking for 
> via the render SPU).  Is there some easy way to set the pixel format?  I 
> ultimately hacked on opengl_stub/wgl.c until it worked, but I didn't 
> include these changes in this patch because there might have been a good 
> reason for always using Pixel Format 1.  I'm using an NV40 card on 
> Windows XP, in case that helps.

Someone with more WGL experience than I will have to help with that.

I'll try to get to your patch by the end of the week.  I also want to 
try to put together a Cr 1.8 release candidate soon.

-Brian

[Chromium-dev] VBO support in array SPU

[Peter D. <dj...@cs...>]

Sorry if you receive this email more than once.  I sent the original 
version to the dev list about a week and a half ago (before I was a list 
member), and that email still has not gone through the moderation process, 
so I thought I'd resubmit.  -- Peter

Here's the original message:

Hi, I've been working on Chromium for some time now trying to get Doom 3 
to run smoothly on it.  I added support for Vertex Buffer Objects (VBO's) 
in the array SPU and wanted to submit my changes for review.  I've tested 
my modified version on a handful of applications that use VBO's and normal 
vertex arrays, and it seems OK so far.  Here's what I've included:

1.  Attached, an archive containing patches to the array SPU that adds 
support for regular VBO arays and for VBO element arrays.  A minor 
(hopefully correct) fix is also included for the buffer object in the 
state tracker.  This patch is diff'd with the cvs repository from Mar 1.

2.  Below, a summary of what changes I made and where, for anyone 
interested.

3.  Below, questions I came across while putting together the patch.  If 
anyone could answer these, I'd really appreciate it.

        Sincerely,
        Peter Djeu


<<< Summary >>>


spu/array/arrayspu.c
    - For the array SPU -- added offset calculations whenever a client 
pointer has valid data in its VBO data ptr.  All uses are protected by a 
#define guard so that the calculations are only done when the Vertex 
Bufffer Object extension is enabled in cr_version.h.

    - Added missing gl function "IndexPointer" to pass along the color index 
pointer to crStateIndexPointer().

    - Added gl functions to pass along all VBO interface calls to the 
corresponding state tracker functions.

    - Added support in DrawElements() for Vertex Buffer Object element 
arrays.


spu/array/arrayspu_init.c
    - For the array SPU -- on context initialization, if the Vertex Buffer 
Object extension is enabled, set the buffer object's retainData flag to 
GL_TRUE.


state_tracker/state_bufferobject.c
    - In the state tracker for VBO's -- when the null buffer is first 
initialized in crStateBufferObjectInit(), its reference count is set to 2. 
However, if the arrayBuffer and elementsBuffer both enter use, then the 
nullBuffer reference count drops to 0, which causes an unnecessary attempt 
to remove it from the hash table every time it is swapped out.  A fix is 
added to set the reference count to 3 on initialization (this also makes 
more sense since the nullBuffer is being pointed to by 3 pointers anyway).

    - In crStateDeleteBuffersARB(), added a line to increment the reference 
count of the nullBuffer when it replaces either arrayBuffer or 
elementsBuffer. Otherwise, repeated swapping out of the nullBuffer causes 
its reference count to wrap around, which is harmless although odd.


<<< Questions >>>

Each question is preceded by the file it pertains to.

* state_tracker/state_bufferobject.c

    - Why are there ref counts within CRBufferObject's?  We can't free the 
data associated with a buffer or remove it from the hashtable unless the 
buffer is explicitly deleted by a DeleteBuffersARB call, so it seems 
unusual what there is even logic present that frees a buffer when its ref 
count drops to zero.  Also, because the buffer object initializer starts 
the refcount at 1 and it immediately gets incremented to 2 
(newObj->refCount++;) in crStateBindBufferARB(), no buffer object, except 
for the nullBuffer, will ever get swapped out enough times for its ref 
count to reach zero.

* spu/array/arrayspu.c

    - Is it customary to NOT put #define guards around entire GL functions 
in a SPU, but to use them within the body of a parent function call?  For 
example, use of the fog coordinate pointer is protected with a "#ifdef 
CR_EXT_fog_coord" guard within arrayspu_ArrayElement(). However, at the 
top level, the function arrayspu_FogCoordPointerEXT(), at both its 
definition and listing in the SPU's named function table, do not have this 
guard.  I have tried to follow the existing standard in the current patch, 
but I can submit an update if using the missing guards everywhere is more 
correct.

* opengl_stub/wgl.c

    - I had a lot of trouble (on Windows) trying to get Chromium to choose 
the right pixel format for the render window (it was always selecting 
Pixel Format 1, despite the visual attributes I was asking for via the 
render SPU).  Is there some easy way to set the pixel format?  I 
ultimately hacked on opengl_stub/wgl.c until it worked, but I didn't 
include these changes in this patch because there might have been a good 
reason for always using Pixel Format 1.  I'm using an NV40 card on Windows 
XP, in case that helps.

EOF

Re: [Chromium-dev] gl calls before context set up = crash!

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

Sean Ahern wrote:
> ma...@co... wrote:
> 
>>Serves me right for not starting from the CVS version (I started out
>>in November and only grabbed the 1.7 release...)
>>
>>You added the glim initialization into NULLfuncs on Jun 24th last
>>year!  Greg was onto something afterall!
> 
> 
> We should probably think about putting out a 1.8 version sometime this
> spring or early summer.  There are a good number of improvements that
> people just aren't seeing if they don't bite the bullet and go with CVS.

Yeah, I meant to do that by the end of last year, but didn't find the 
time.

Maybe I should just bite the bullet and put together a release 
candidate next week, wait a couple days, then release 1.8.

-Brian

Re: [Chromium-dev] gl calls before context set up = crash!

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

ma...@co... wrote:
> Serves me right for not starting from the CVS version (I started out
> in November and only grabbed the 1.7 release...)
> 
> You added the glim initialization into NULLfuncs on Jun 24th last
> year!  Greg was onto something afterall!

We should probably think about putting out a 1.8 version sometime this
spring or early summer.  There are a good number of improvements that
people just aren't seeing if they don't bite the bullet and go with CVS.

-Sean

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

Re: [Chromium-dev] help with render spu

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

Aditya Kulkarni wrote:
> Hello all,
> 
> I am a newbie to Chromium. I went through a bit of chromium code, and
> understood how SPUs are loaded. Now I want to understand render spu in
> detail. Is there some documentation available with any one of you
> which gives -
> 
> [1] A high level description of what render spu is supposed to do.

It basically passes all the OpenGL calls to the underlying OpenGL library.


> [2] Details of what function in code of render spu implements what.

I think most functions are self-explanatory.  renderspuCreateContext() 
creates a rendering context, renderspuSwapBuffers() does front/back 
color buffer swaps, etc.


> If you could point out some sequence that I should follow while
> browsing the code of render spu, that would be great.

I think if you just spend some time reading the code it'll become 
clear.  It's really pretty simple stuff.

-Brian

[Chromium-dev] help with render spu

[Aditya K. <adi...@gm...>]

Hello all,

I am a newbie to Chromium. I went through a bit of chromium code, and
understood how SPUs are loaded. Now I want to understand render spu in
detail. Is there some documentation available with any one of you
which gives -

[1] A high level description of what render spu is supposed to do.
[2] Details of what function in code of render spu implements what.

If you could point out some sequence that I should follow while
browsing the code of render spu, that would be great.

-- 
Thanks,
Aditya Kulkarni

Re: [Chromium-dev] gl calls before context set up = crash!

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

ma...@co... wrote:
> Brian,
> 
> Serves me right for not starting from the CVS version (I started out in
> November and only grabbed the 1.7 release...)
> 
> You added the glim initialization into NULLfuncs on Jun 24th last year! Greg
> was onto something afterall!
> 
> Sorry to bug you about all that...

No problem.  I backed out yesterday's change from CVS.


> Thanks,
> Jon
> 
> ps. Am I at least right about params[17] in tilesortspu_stereo.c needing to be
> params[18]? (See my previous message or my bugreport on sourceforge for a few
> more details...)

I just checked in the fix.  Thanks!

-Brian


> Quoting Brian Paul <bri...@tu...>:
> 
> 
>>I can add the two lines you listed below, but I guess I don't
>>understand why the no-op functions aren't working as-is.
>>
>>In NULLfuncs.c the glim table is statically initialized:
>>
>>/* Declare and initialize the glim dispatch table here so that we */
>>/* can initialize all entries to no-op routines. */
>>SPUDispatchTable glim = {
>>	NULL_Accum,
>>	NULL_ActiveTextureARB,
>>	NULL_AlphaFunc,
>>	NULL_AreProgramsResidentNV,
>>[...]
>>
>>
>>That _should_ be sufficient.  Perhaps I'm missing some subtle aspect
>>of the Windows code though.
>>
>>-Brian
>>
>>
> 
> 

Re: [Chromium-dev] gl calls before context set up = crash!

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

Brian,

Serves me right for not starting from the CVS version (I started out in
November and only grabbed the 1.7 release...)

You added the glim initialization into NULLfuncs on Jun 24th last year! Greg
was onto something afterall!

Sorry to bug you about all that...

Thanks,
Jon

ps. Am I at least right about params[17] in tilesortspu_stereo.c needing to be
params[18]? (See my previous message or my bugreport on sourceforge for a few
more details...)



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

>
> I can add the two lines you listed below, but I guess I don't
> understand why the no-op functions aren't working as-is.
>
> In NULLfuncs.c the glim table is statically initialized:
>
> /* Declare and initialize the glim dispatch table here so that we */
> /* can initialize all entries to no-op routines. */
> SPUDispatchTable glim = {
> 	NULL_Accum,
> 	NULL_ActiveTextureARB,
> 	NULL_AlphaFunc,
> 	NULL_AreProgramsResidentNV,
> [...]
>
>
> That _should_ be sufficient.  Perhaps I'm missing some subtle aspect
> of the Windows code though.
>
> -Brian
>
>

Re: [Chromium-dev] gl calls before context set up = crash!

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

I can add the two lines you listed below, but I guess I don't 
understand why the no-op functions aren't working as-is.

In NULLfuncs.c the glim table is statically initialized:

/* Declare and initialize the glim dispatch table here so that we */
/* can initialize all entries to no-op routines. */
SPUDispatchTable glim = {
	NULL_Accum,
	NULL_ActiveTextureARB,
	NULL_AlphaFunc,
	NULL_AreProgramsResidentNV,
[...]


That _should_ be sufficient.  Perhaps I'm missing some subtle aspect 
of the Windows code though.

-Brian


ma...@co... wrote:
> Hi Brian and Greg,
> 
> The function stubInit apparently gets glim initialized, but it is only called
> (on Windows anyway) from the functions in wgl.c which have to do with context
> creation, etc... So glim isn't initialized to the null funcs at load time...
> 
> But if you add the following to DllMain at the Bottom of load.c this seems to
> do the trick:
> 
> crSPUInitDispatchTable( &glim );
> crSPUCopyDispatchTable(&glim, &stubNULLDispatch);
> 
> Now the 3rd-party app gets far enough to say it can't get a PixelFormat it
> likes.. But we'll take it from there for now!
> 
> Thanks,
> Jon
> 
> ps. If noone has seen the bug report on sourceforge, I'm pretty sure that
> the "params" array in tilesortspu_stereo.c should be 18 elements long rather
> than 17. It's at line 109 in the version I have.
> 
> 
> 
> 
> 
> Quoting Brian Paul <bri...@tu...>:
> 
> 
>>Initially, all functions are supposed to jump into no-op functions.
>>
>>In the NULLfuncs.c file, when we declare (define?) the glim table, we
>>initialize all the pointers to no-op functions.
>>
>>Jonathan, could you use a debugger to examine the value of
>>glim.SomeFunc to make sure it points to a null/no-op function?
>>
>>-Brian
>>
>>Greg Humphreys wrote:
>>
>>>I'm pretty sure that at some point in the past glim was set up to
>>>point to the NOP spu, which was always loaded by default.  Has this
>>>changed?
>>>
>>>
>>>On Fri, 25 Feb 2005 19:46:15 -0700, ma...@co...
>>><ma...@co...> wrote:
>>>
>>>
>>>>Hi all,
>>>>
>>>>My research group is working on some modifications to Cr to allow
>>
>>head-tracked
>>
>>>>stereo for CAVE-type environments and we've had some good success!
>>>>
>>>>But I've run into a nasty problem: we're running a 3rd-party client app
>>
>>that's
>>
>>>>very naughty... It appears to be calling gl calls before setting up its
>>>>rendering context.
>>>>
>>>>We're working on Windows, starting from the 1.7 release code (I know, I
>>
>>should
>>
>>>>probably grab what's in CVS...) and the functions in windows_exports.c
>>>>typically do the following:
>>>>
>>>>NAKED void cr_SomeFunc( argsGoHere )
>>>>{
>>>>       __asm jmp [glim.SomeFunc]
>>>>       UNUSED( argsGoHere );
>>>>}
>>>>
>>>>I haven't dug too far into this yet, but I think this blind jmp is the
>>>>problem, since glim hasn't been set up yet. We would either need to test
>>
>>for
>>
>>>>this or glim needs to be set up sooner...
>>>>
>>>>Can anyone comment on what would be involved in getting a high-performance
>>>>work-around going for this degenerate case!
>>>>
>>>>Thanks,
>>>>Jon
>>>>
>>>>Jonathan Marbach
>>>>BP Center for Visualization
>>>>3400 Marine St.
>>>>Boulder, CO 80218
>>>>www.bpvizcenter.com
>>>>
>>>>-------------------------------------------------------
>>>>SF email is sponsored by - The IT Product Guide
>>>>Read honest & candid reviews on hundreds of IT Products from real users.
>>>>Discover which products truly live up to the hype. Start reading now.
>>>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>>>_______________________________________________
>>>>Chromium-dev mailing list
>>>>Chr...@li...
>>>>https://lists.sourceforge.net/lists/listinfo/chromium-dev
>>>>
>>>>
>>>
>>>
>>>
> 
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev
> 

Re: [Chromium-dev] Problems with shutdown of crserver for non-tcpip connections

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

sea...@ll... said:
> Dumb question: Can you run one of the back end crservers in gdb, and
> have it follow the parent or break on fork()?  That would give you a
> hint as to what's going on.

> -Sean 

I've finally gotten around to implementing Sean's suggestion, and I've found 
that the process causing all the problems is created by clone() rather than 
fork() or its variants.  It's being created in elan3_attach(), which is a call 
used in management of the Quadrics device.  Apparently the Quadrics folks have 
added a watcher process of some sort in their most recent software release and 
that process is surviving the teardown process for the crserver.  My 
apologies; this problem shouldn't be common to other networks like GM.  I'll 
figure out what is supposed to make that process die and see if I can get the 
crserver teardown to do it.

-Joel
 we...@ps...

Re: [Chromium-dev] gl calls before context set up = crash!

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

Hi Brian and Greg,

The function stubInit apparently gets glim initialized, but it is only called
(on Windows anyway) from the functions in wgl.c which have to do with context
creation, etc... So glim isn't initialized to the null funcs at load time...

But if you add the following to DllMain at the Bottom of load.c this seems to
do the trick:

crSPUInitDispatchTable( &glim );
crSPUCopyDispatchTable(&glim, &stubNULLDispatch);

Now the 3rd-party app gets far enough to say it can't get a PixelFormat it
likes.. But we'll take it from there for now!

Thanks,
Jon

ps. If noone has seen the bug report on sourceforge, I'm pretty sure that
the "params" array in tilesortspu_stereo.c should be 18 elements long rather
than 17. It's at line 109 in the version I have.





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

> Initially, all functions are supposed to jump into no-op functions.
>
> In the NULLfuncs.c file, when we declare (define?) the glim table, we
> initialize all the pointers to no-op functions.
>
> Jonathan, could you use a debugger to examine the value of
> glim.SomeFunc to make sure it points to a null/no-op function?
>
> -Brian
>
> Greg Humphreys wrote:
> > I'm pretty sure that at some point in the past glim was set up to
> > point to the NOP spu, which was always loaded by default.  Has this
> > changed?
> >
> >
> > On Fri, 25 Feb 2005 19:46:15 -0700, ma...@co...
> > <ma...@co...> wrote:
> >
> >>Hi all,
> >>
> >>My research group is working on some modifications to Cr to allow
> head-tracked
> >>stereo for CAVE-type environments and we've had some good success!
> >>
> >>But I've run into a nasty problem: we're running a 3rd-party client app
> that's
> >>very naughty... It appears to be calling gl calls before setting up its
> >>rendering context.
> >>
> >>We're working on Windows, starting from the 1.7 release code (I know, I
> should
> >>probably grab what's in CVS...) and the functions in windows_exports.c
> >>typically do the following:
> >>
> >>NAKED void cr_SomeFunc( argsGoHere )
> >>{
> >>        __asm jmp [glim.SomeFunc]
> >>        UNUSED( argsGoHere );
> >>}
> >>
> >>I haven't dug too far into this yet, but I think this blind jmp is the
> >>problem, since glim hasn't been set up yet. We would either need to test
> for
> >>this or glim needs to be set up sooner...
> >>
> >>Can anyone comment on what would be involved in getting a high-performance
> >>work-around going for this degenerate case!
> >>
> >>Thanks,
> >>Jon
> >>
> >>Jonathan Marbach
> >>BP Center for Visualization
> >>3400 Marine St.
> >>Boulder, CO 80218
> >>www.bpvizcenter.com
> >>
> >>-------------------------------------------------------
> >>SF email is sponsored by - The IT Product Guide
> >>Read honest & candid reviews on hundreds of IT Products from real users.
> >>Discover which products truly live up to the hype. Start reading now.
> >>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> >>_______________________________________________
> >>Chromium-dev mailing list
> >>Chr...@li...
> >>https://lists.sourceforge.net/lists/listinfo/chromium-dev
> >>
> >>
> >
> >
> >
>

Re: [Chromium-dev] gl calls before context set up = crash!

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

Initially, all functions are supposed to jump into no-op functions.

In the NULLfuncs.c file, when we declare (define?) the glim table, we 
initialize all the pointers to no-op functions.

Jonathan, could you use a debugger to examine the value of 
glim.SomeFunc to make sure it points to a null/no-op function?

-Brian

Greg Humphreys wrote:
> I'm pretty sure that at some point in the past glim was set up to
> point to the NOP spu, which was always loaded by default.  Has this
> changed?
> 
> 
> On Fri, 25 Feb 2005 19:46:15 -0700, ma...@co...
> <ma...@co...> wrote:
> 
>>Hi all,
>>
>>My research group is working on some modifications to Cr to allow head-tracked
>>stereo for CAVE-type environments and we've had some good success!
>>
>>But I've run into a nasty problem: we're running a 3rd-party client app that's
>>very naughty... It appears to be calling gl calls before setting up its
>>rendering context.
>>
>>We're working on Windows, starting from the 1.7 release code (I know, I should
>>probably grab what's in CVS...) and the functions in windows_exports.c
>>typically do the following:
>>
>>NAKED void cr_SomeFunc( argsGoHere )
>>{
>>        __asm jmp [glim.SomeFunc]
>>        UNUSED( argsGoHere );
>>}
>>
>>I haven't dug too far into this yet, but I think this blind jmp is the
>>problem, since glim hasn't been set up yet. We would either need to test for
>>this or glim needs to be set up sooner...
>>
>>Can anyone comment on what would be involved in getting a high-performance
>>work-around going for this degenerate case!
>>
>>Thanks,
>>Jon
>>
>>Jonathan Marbach
>>BP Center for Visualization
>>3400 Marine St.
>>Boulder, CO 80218
>>www.bpvizcenter.com
>>
>>-------------------------------------------------------
>>SF email is sponsored by - The IT Product Guide
>>Read honest & candid reviews on hundreds of IT Products from real users.
>>Discover which products truly live up to the hype. Start reading now.
>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>_______________________________________________
>>Chromium-dev mailing list
>>Chr...@li...
>>https://lists.sourceforge.net/lists/listinfo/chromium-dev
>>
>>
> 
> 
> 

Re: [Chromium-dev] gl calls before context set up = crash!

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

I'm pretty sure that at some point in the past glim was set up to
point to the NOP spu, which was always loaded by default.  Has this
changed?


On Fri, 25 Feb 2005 19:46:15 -0700, ma...@co...
<ma...@co...> wrote:
> Hi all,
> 
> My research group is working on some modifications to Cr to allow head-tracked
> stereo for CAVE-type environments and we've had some good success!
> 
> But I've run into a nasty problem: we're running a 3rd-party client app that's
> very naughty... It appears to be calling gl calls before setting up its
> rendering context.
> 
> We're working on Windows, starting from the 1.7 release code (I know, I should
> probably grab what's in CVS...) and the functions in windows_exports.c
> typically do the following:
> 
> NAKED void cr_SomeFunc( argsGoHere )
> {
>         __asm jmp [glim.SomeFunc]
>         UNUSED( argsGoHere );
> }
> 
> I haven't dug too far into this yet, but I think this blind jmp is the
> problem, since glim hasn't been set up yet. We would either need to test for
> this or glim needs to be set up sooner...
> 
> Can anyone comment on what would be involved in getting a high-performance
> work-around going for this degenerate case!
> 
> Thanks,
> Jon
> 
> Jonathan Marbach
> BP Center for Visualization
> 3400 Marine St.
> Boulder, CO 80218
> www.bpvizcenter.com
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&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/

[Chromium-dev] gl calls before context set up = crash!

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

Hi all,

My research group is working on some modifications to Cr to allow head-tracked
stereo for CAVE-type environments and we've had some good success!

But I've run into a nasty problem: we're running a 3rd-party client app that's
very naughty... It appears to be calling gl calls before setting up its
rendering context.

We're working on Windows, starting from the 1.7 release code (I know, I should
probably grab what's in CVS...) and the functions in windows_exports.c
typically do the following:

NAKED void cr_SomeFunc( argsGoHere )
{
	__asm jmp [glim.SomeFunc]
	UNUSED( argsGoHere );
}

I haven't dug too far into this yet, but I think this blind jmp is the
problem, since glim hasn't been set up yet. We would either need to test for
this or glim needs to be set up sooner...

Can anyone comment on what would be involved in getting a high-performance
work-around going for this degenerate case!

Thanks,
Jon


Jonathan Marbach
BP Center for Visualization
3400 Marine St.
Boulder, CO 80218
www.bpvizcenter.com

Re: [Chromium-dev] Implementing the GL_EXT_bgra extention

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

brendan powers wrote:
> Hi. I am interested in implementing the GL_EXT_bgra extention. It
> looks fairly simple, becuase no new function were added to this
> extention. New toekns were added for a fiew functions. See
> http://www.msi.unilim.fr/~porquet/glexts/GL_EXT_bgra.txt.html.   I
> have read the sections in the documentation about adding extensions.
> They are a bit vague and seem a little out of date.

probably.


> How hard would implementing this function be?
> Any pointers to make it easier?

Basically, any place that GL_RGBA is accepted, GL_BGRA will also be 
accepted.  So, I'd start with a grep of the sources for GL_RGBA.  Most 
changes should be trivial.

One place that will require more attention is the util/pixel.c file. 
That's where pixel packing/unpacking is done.

state_limits.c and cr_extstring.h will also need updates.

-Brian

[Chromium-dev] Implementing the GL_EXT_bgra extention

[brendan p. <bre...@gm...>]

Hi. I am interested in implementing the GL_EXT_bgra extention. It
looks fairly simple, becuase no new function were added to this
extention. New toekns were added for a fiew functions. See
http://www.msi.unilim.fr/~porquet/glexts/GL_EXT_bgra.txt.html.   I
have read the sections in the documentation about adding extensions.
They are a bit vague and seem a little out of date.

How hard would implementing this function be?
Any pointers to make it easier?

Thanks.

Re: [Chromium-dev] Problems with shutdown of crserver for non-tcpip connections

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

Joel Welling wrote:
> Definitely not.  I've been painstakingly killing them, and all the
> crservers in the batch I'm looking at have consecutive PIDs.  The 2
> children list the first crserver as their parent.

Dumb question: Can you run one of the back end crservers in gdb, and
have it follow the parent or break on fork()?  That would give you a
hint as to what's going on.

-Sean

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

Re: [Chromium-dev] Problems with shutdown of crserver for non-tcpip connections

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

Brian Paul wrote:
> I do not see that.  Are you sure one of the crserver processes isn't 
> lingering around from a previous run?

Definitely not.  I've been painstakingly killing them, and all the crservers 
in the batch I'm looking at have consecutive PIDs.  The 2 children list the 
first crserver as their parent.
 
> 
> > Is this maybe somehow a consequence of 
> > having compiled in teac communication, even if it is not used?
> 
> Perhaps.  I can't run/test the teac/GM stuff here.
> 
> -Brian

-Joel

> Joel Welling wrote:
> > Brian Paul wrote:
> >>Joel Welling wrote:
> >>
> >>>Hi folks;
> >>>  I'm encountering a problem managing the crserver processes for configs in 
> >>>which I use the teac network mechanism; I think it will also be seen in things 
> >>>like GM.  When I spawn the crserver I keep track of its PID, and when I want 
> >>>it to terminate I send a TERM signal to that PID.  Fair enough; the process 
> >>>that got that signal terminates, running through the 'teardown' routine in the 
> >>>crserverlib code.
> >>>  The problem is, by this time the crserver has spawned 2 child processes.  I 
> >>>believe they are actually other threads, but I'm not sure- I know they are not 
> >>>being created with crSpawn().  One of those threads is very, very busy doing a 
> >>>wait loop, waiting for messages on my high-bandwidth network.  That process, 
> >>>and the third process which is its child, do *not* die when their parent (the 
> >>>originally spawned process) gets the TERM signal.
> >>>  Can anyone confirm for me that these are threads, and tell me which bit of 
> >>>code is likely to be spawning them?  Are their PIDs or thread IDs getting 
> >>>saved anywhere?  I can modify the teardown procedure to kill them if I have 
> >>>their names, but I can't simply kill the whole process group- that kills 
> >>>innocent bystanders.
> >>
> > 
> >>I don't know how the crserver would be spawning any threads.  The 
> >>crserver itself isn't even thread-safe.
> >>
> >>Are you sure the GM library isn't creating the threads?
> >>
> >>-Brian
> > 
> > 
> > teac.c isn't doing it directly, but it could be a side effect of the message 
> > buffer management code which is common to teac.c and (say) GM.
> > 
> > If I use a .conf file with only tcpip connections, crserver still spawns a 
> > second process; it's easy to see this with a 'ps'.  The process starts up 
> > immediately after crserver starts up, before the SPU network is fully 
> > established.  Do you not see this?
> 

Re: [Chromium-dev] Problems with shutdown of crserver for non-tcpip connections

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

Joel Welling wrote:
> Brian Paul wrote:
>>Joel Welling wrote:
>>
>>>Hi folks;
>>>  I'm encountering a problem managing the crserver processes for configs in 
>>>which I use the teac network mechanism; I think it will also be seen in things 
>>>like GM.  When I spawn the crserver I keep track of its PID, and when I want 
>>>it to terminate I send a TERM signal to that PID.  Fair enough; the process 
>>>that got that signal terminates, running through the 'teardown' routine in the 
>>>crserverlib code.
>>>  The problem is, by this time the crserver has spawned 2 child processes.  I 
>>>believe they are actually other threads, but I'm not sure- I know they are not 
>>>being created with crSpawn().  One of those threads is very, very busy doing a 
>>>wait loop, waiting for messages on my high-bandwidth network.  That process, 
>>>and the third process which is its child, do *not* die when their parent (the 
>>>originally spawned process) gets the TERM signal.
>>>  Can anyone confirm for me that these are threads, and tell me which bit of 
>>>code is likely to be spawning them?  Are their PIDs or thread IDs getting 
>>>saved anywhere?  I can modify the teardown procedure to kill them if I have 
>>>their names, but I can't simply kill the whole process group- that kills 
>>>innocent bystanders.
>>
> 
>>I don't know how the crserver would be spawning any threads.  The 
>>crserver itself isn't even thread-safe.
>>
>>Are you sure the GM library isn't creating the threads?
>>
>>-Brian
> 
> 
> teac.c isn't doing it directly, but it could be a side effect of the message 
> buffer management code which is common to teac.c and (say) GM.
> 
> If I use a .conf file with only tcpip connections, crserver still spawns a 
> second process; it's easy to see this with a 'ps'.  The process starts up 
> immediately after crserver starts up, before the SPU network is fully 
> established.  Do you not see this?

I do not see that.  Are you sure one of the crserver processes isn't 
lingering around from a previous run?


> Is this maybe somehow a consequence of 
> having compiled in teac communication, even if it is not used?

Perhaps.  I can't run/test the teac/GM stuff here.

-Brian

Re: [Chromium-dev] Problems with shutdown of crserver for non-tcpip connections

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

Brian Paul wrote:
> I don't know how the crserver would be spawning any threads.  The 
> crserver itself isn't even thread-safe.
> 
> Are you sure the GM library isn't creating the threads?
> 
> -Brian

teac.c isn't doing it directly, but it could be a side effect of the message 
buffer management code which is common to teac.c and (say) GM.

If I use a .conf file with only tcpip connections, crserver still spawns a 
second process; it's easy to see this with a 'ps'.  The process starts up 
immediately after crserver starts up, before the SPU network is fully 
established.  Do you not see this?  Is this maybe somehow a consequence of 
having compiled in teac communication, even if it is not used?

-Joel

> Joel Welling wrote:
> > Hi folks;
> >   I'm encountering a problem managing the crserver processes for configs in 
> > which I use the teac network mechanism; I think it will also be seen in things 
> > like GM.  When I spawn the crserver I keep track of its PID, and when I want 
> > it to terminate I send a TERM signal to that PID.  Fair enough; the process 
> > that got that signal terminates, running through the 'teardown' routine in the 
> > crserverlib code.
> >   The problem is, by this time the crserver has spawned 2 child processes.  I 
> > believe they are actually other threads, but I'm not sure- I know they are not 
> > being created with crSpawn().  One of those threads is very, very busy doing a 
> > wait loop, waiting for messages on my high-bandwidth network.  That process, 
> > and the third process which is its child, do *not* die when their parent (the 
> > originally spawned process) gets the TERM signal.
> >   Can anyone confirm for me that these are threads, and tell me which bit of 
> > code is likely to be spawning them?  Are their PIDs or thread IDs getting 
> > saved anywhere?  I can modify the teardown procedure to kill them if I have 
> > their names, but I can't simply kill the whole process group- that kills 
> > innocent bystanders.
> 

Re: [Chromium-dev] Problems with shutdown of crserver for non-tcpip connections

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

Brian Paul wrote:

> Joel Welling wrote:
>
>> Hi folks;
>>   I'm encountering a problem managing the crserver processes for 
>> configs in which I use the teac network mechanism; I think it will 
>> also be seen in things like GM.  When I spawn the crserver I keep 
>> track of its PID, and when I want it to terminate I send a TERM 
>> signal to that PID.  Fair enough; the process that got that signal 
>> terminates, running through the 'teardown' routine in the crserverlib 
>> code.
>>   The problem is, by this time the crserver has spawned 2 child 
>> processes.  I believe they are actually other threads, but I'm not 
>> sure- I know they are not being created with crSpawn().  One of those 
>> threads is very, very busy doing a wait loop, waiting for messages on 
>> my high-bandwidth network.  That process, and the third process which 
>> is its child, do *not* die when their parent (the originally spawned 
>> process) gets the TERM signal.
>>   Can anyone confirm for me that these are threads, and tell me which 
>> bit of code is likely to be spawning them?  Are their PIDs or thread 
>> IDs getting saved anywhere?  I can modify the teardown procedure to 
>> kill them if I have their names, but I can't simply kill the whole 
>> process group- that kills innocent bystanders.
>
>
> I don't know how the crserver would be spawning any threads.  The 
> crserver itself isn't even thread-safe.
>
> Are you sure the GM library isn't creating the threads?
>
> -Brian
>
I also haven't seen the threading behavior, but I have seen the networks 
hang.  The issue has been that faking a connection based protocol on 
connectionless networks (Quadrics/Myrinet/IB) has had an issue with 
shutdowns for as long as I can remember.  Sometimes things work 
correctly if the application exits cleanly so that signals to terminate 
are passed around, but killing one of the applications or servers can 
cause the others to hang.

I'm not sure what the best solution here is.  Maybe we need to start 
trapping all of the signals on the nodes to make sure to shut the 
connections down. Another, potentially better, option is to rely on the 
mothership's connection brokering.  If the mothership loses a connection 
to anyone in the group, send a notification to the others that things 
should terminate.  The layers, other than tcp/sdp/udp, will need to 
timeout on waitrecv and test the mothership connection.  This might also 
fix the deadlock detect and hang problem that happens occasionally.

In general, this points to a  network layer rewrite that we have talked 
about off and on for the past two years.  There is some cruftyness in 
writing highspeed layers.  It seems that instead of choosing to make 
everything look like tcpip, we might want to find a more general 
abstraction and map the layers to that, something like a point2point 
layer (i.e. send this message to this system(s), without enforcing 
connection semantics).  For example, there is an MPI layer branched in 
CVS that is getting painful to get working in general cases, mainly 
because of reliance on special process creation semantics and the 
enforcement of connection based networking semantics.  The reason it's 
hard to get a network rewrite done is the shear time commitment involved 
and not everyone has access to all of the different network systems.  
Although, many interconnects are now supporting socket interfaces and 
*DAPL (*=u/k/s), which might make for more simplified porting efforts.

-Mike

Re: [Chromium-dev] Problems with shutdown of crserver for non-tcpip connections

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

Joel Welling wrote:
> Hi folks;
>   I'm encountering a problem managing the crserver processes for configs in 
> which I use the teac network mechanism; I think it will also be seen in things 
> like GM.  When I spawn the crserver I keep track of its PID, and when I want 
> it to terminate I send a TERM signal to that PID.  Fair enough; the process 
> that got that signal terminates, running through the 'teardown' routine in the 
> crserverlib code.
>   The problem is, by this time the crserver has spawned 2 child processes.  I 
> believe they are actually other threads, but I'm not sure- I know they are not 
> being created with crSpawn().  One of those threads is very, very busy doing a 
> wait loop, waiting for messages on my high-bandwidth network.  That process, 
> and the third process which is its child, do *not* die when their parent (the 
> originally spawned process) gets the TERM signal.
>   Can anyone confirm for me that these are threads, and tell me which bit of 
> code is likely to be spawning them?  Are their PIDs or thread IDs getting 
> saved anywhere?  I can modify the teardown procedure to kill them if I have 
> their names, but I can't simply kill the whole process group- that kills 
> innocent bystanders.

I don't know how the crserver would be spawning any threads.  The 
crserver itself isn't even thread-safe.

Are you sure the GM library isn't creating the threads?

-Brian