Menu
▾
▴
chromium-dev
|
From: <ma...@co...> - 2005-02-26 02:46:23
|
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
|
|
From: Greg H. <hu...@gm...> - 2005-02-26 03:10:19
|
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/
|
|
From: Brian P. <bri...@tu...> - 2005-02-26 17:33:57
|
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
>>
>>
>
>
>
|
|
From: <ma...@co...> - 2005-02-28 23:50:32
|
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
> >>
> >>
> >
> >
> >
>
|
|
From: Brian P. <bri...@tu...> - 2005-03-02 00:19:50
|
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
>
|
|
From: <ma...@co...> - 2005-03-02 01:01:20
|
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
>
>
|
|
From: Brian P. <bri...@tu...> - 2005-03-02 14:06:36
|
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
>>
>>
>
>
|
|
From: Sean A. <sea...@ll...> - 2005-03-11 17:29:38
|
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 |
|
From: Brian P. <bri...@tu...> - 2005-03-11 17:45:02
|
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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X