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

Re: [Chromium-dev] [RFC] Patch for VNC SPU getting "stuck"

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

Niraj Tolia wrote:
> This report is against CVS HEAD. With the last round of changes, the 
> Async IO code path will block everytime there is no update to send. The 
> relevant stack trace is
> 
> #3  0x00a63d75 in crWaitSemaphore (s=0xca46b8) at threads.c:259
> #4  0x00c8786c in vncspuWaitDirtyRects (region=0xa246884, 
> frame_num=0xa2469e8)
>     at vncspu.c:335
> #5  0x00c8b13e in rf_client_updatereq () at client_io.c:516
> #6  0x00c8989d in aio_process_input (slot=0xa246728) at async_io.c:562
> #7  0x00c89486 in aio_mainloop () at async_io.c:390
> 
> We never ran into this issue earlier as the VNC SPU had a fixed frame 
> update rate and we would always have something to send out. However, now 
> we can get stuck because of the above. Things that the user runs into 
> includes attempts at new connections "hanging". This happens because we 
> never return to the aio_mainloop unless an update was received from the 
> remote application running under crappfaker.

The CVS HEAD code should work fine for a single VNC viewer, but I can 
see how it would hang with multiple viewers.  I hadn't gotten around 
to fixing that yet.


> As we already record that an update was requested on the current client 
> slot, one option is to return to the aio_mainloop and defer sending the 
> update till something is actually available. The deferred update can be 
> sent by leveraging the s_idle_func used in the AIO code. An example 
> patch of how this could be done is attached. One disadvantage is that we 
> need to reduce the timeout value of the select() call in aio_mainloop(). 
> Testing did not indicate any increased CPU usage though as the idle 
> function is cheap.
> 
> I have a decent handle on the VNC SPU code and so, if you feel this 
> should be done differently, just let me know and I should be able to 
> code up another patch.

Even with your patch, when I attach two VNC viewers, things aren't 
running as expected.  One viewer or the other will freeze up for long 
periods.

I'm looking into it.  I may not have a fix until next week though.

-Brian

Re: [Chromium-dev] Windows broken build

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

Michael D=FCrig wrote:
>=20
> I had to apply the following patch in order to get Chromium to build on=
=20
> Windows.

Thanks, Michael.  I've checked in your patches.

-Brian

[Chromium-dev] Windows broken build

[<dr...@bf...>]

I had to apply the following patch in order to get Chromium to build on 
Windows.

Michael

Re: [Chromium-dev] VNC SPU not sending frame updates, currDirtyRegion being the cause

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

Andres Lagar Cavilla wrote:
> Hi,
> I just checked out the cvs head. I'm using one of the demo apps, city
> and a vnc spu. If I connect a vncviewer to the vnc reflector offered by
> the spu, I get no updates, only a blank screen. I believe this has been
> reported before.
> 
> I've looked into the code and so far identified that the currDirtyRegion
> struct is *never* updated. Therefore the SPU thinks there isn'y anything
> dirty to put into a framebuffer update.
> 
> A quick hack by forcing newWindowSize to true (and therefore filling the
> dirtyRegion with the whole window) confirms this is the case:
> framebuffer updates will be sent to the vncviewer. The same happens if I 
> disable "use_bounding_boxes"
> 
> Even with this quick fix, framebuffer updates are sent to the viewer in 
> a very choppy manner. I think there is some mishandling of the RFB 
> porotocol going on as well.
> 
> I hope this inspires someone more adept with this code to find the
> appropriate fixes.

I've been working on the VNC SPU quite a bit lately.  I'll look into 
the bounding box problem you describe.

I think I've solved the choppy update problem but I need to do more 
testing before I check in my stuff.  Maybe in a day or two.

-Brian

[Chromium-dev] VNC SPU not sending frame updates, currDirtyRegion being the cause

[Andres L. C. <and...@cs...>]

Hi,
I just checked out the cvs head. I'm using one of the demo apps, city
and a vnc spu. If I connect a vncviewer to the vnc reflector offered by
the spu, I get no updates, only a blank screen. I believe this has been
reported before.

I've looked into the code and so far identified that the currDirtyRegion
struct is *never* updated. Therefore the SPU thinks there isn'y anything
dirty to put into a framebuffer update.

A quick hack by forcing newWindowSize to true (and therefore filling the
dirtyRegion with the whole window) confirms this is the case:
framebuffer updates will be sent to the vncviewer. The same happens if I 
disable "use_bounding_boxes"

Even with this quick fix, framebuffer updates are sent to the viewer in 
a very choppy manner. I think there is some mishandling of the RFB 
porotocol going on as well.

I hope this inspires someone more adept with this code to find the
appropriate fixes.

Thanks a lot
Andres

Re: [Chromium-dev] [PATCH] vncspu.c

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

Niraj Tolia wrote:
> I believe the following test is needed based on the #ifdefs found in the 
> rest of the code. Diff against CVS.

Fixed.

-Brian

[Chromium-dev] [PATCH] vncspu.c

[Niraj T. <nt...@gm...>]

I believe the following test is needed based on the #ifdefs found in the
rest of the code. Diff against CVS.

Niraj

Index: vncspu.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/chromium/cr/spu/vnc/vncspu.c,v
retrieving revision 1.20
diff -u -r1.20 vncspu.c
--- vncspu.c    1 Feb 2006 21:53:31 -0000       1.20
+++ vncspu.c    22 Feb 2006 04:22:48 -0000
@@ -144,7 +144,9 @@
                 * connect the VNC server thread which we just started.
                 */
                CRASSERT(vnc_spu.server_port !=3D -1);
+#if defined(HAVE_VNC_EXT)
                vncspuSendVncStartUpMsg(vnc_spu.server_port);
+#endif
        }
 }



--
http://www.cs.cmu.edu/~ntolia

Re: [Chromium-dev] [PATCH] Fix cvs build

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

Niraj Tolia wrote:
> I could not find a file named dlm_dispatch.h in CVS. This patch fixes 
> the broken build.

Thanks.

-Brian

Re: [Chromium-dev] Status of Infiniband network layer?

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

SDP is in good shape, and I'd suggest using that.  The VAPI layer hasn't 
been converted to the new OpenIB stack, as far as I know, and you don't 
want to use the old drivers that support that API.  SDP support in the 
OpenIB gen 2 stack, i.e. the one in the linux kernel, is pretty good 
(zero-copy, aio support, etc).

Unless you plan to use multi-port/channel or mult-board, SDP will 
probably be your best bet.  If you need to use those advanced features, 
you'll currently need to use raw VAPI, and the layer in Chromium isn't 
up to that.  For all out performance, using VAPI directly will be the 
best thing, but it's going to take a large time commitment to bring that 
layer up to snuff.

-Mike

we...@st... wrote:
> Hi folks;
>   How functional is the current version of the Infiniband network layer? 
> I recall some discussion about instabilities due to variations in vendor
> implementations about a year ago, but I don't recall hearing anything
> since.  We have enough Infiniband machines in house at this point that
> it's become very relevant to us.
>
> Thanks,
> -Joel
>  we...@ps...
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev
>   

[Chromium-dev] Status of Infiniband network layer?

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

Hi folks;
  How functional is the current version of the Infiniband network layer? 
I recall some discussion about instabilities due to variations in vendor
implementations about a year ago, but I don't recall hearing anything
since.  We have enough Infiniband machines in house at this point that
it's become very relevant to us.

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

Re: [Chromium-dev] Break in build on Windows in tilesortspu (THREADSAFE on, amlost cvs state)

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

I've checked in a fix for that.

-Brian

Maciej Donotek wrote:
> Printouts below. I used cvs state for build with one exception I took 
> tilesortspu_pixels.c revision: 1.52 instead of latest  revision: 1.53. 
> With revision 1.53 it is not compiling at all. With 1.52 it can be built 
> with THREADSAFE = off but breaks with THREADSAFE = on (what I really need).
>  
> -- 
> Best regards
> Maciej
>  
> -------------------------------------------------------------------------------
>               Building tilesortspu.dll for WIN_NT (DEBUG) (THREADSAFE) 
> (STATE) (PACK)
> -------------------------------------------------------------------------------
> [...] [Compiling is ok]
> 
> Linking ../../built/tilesortspu/WIN_NT/tilesortspu.dll
>    Creating library ../../built/tilesortspu/WIN_NT/tilesortspu.lib and 
> object ..
> /../built/tilesortspu/WIN_NT/tilesortspu.exp
> tilesortspu_pixels.obj : error LNK2001: unresolved external symbol 
> __PackerTSD
> ../../built/tilesortspu/WIN_NT/tilesortspu.dll : fatal error LNK1120: 1 
> unresolv
> ed externals
> make[2]: *** [../../built/tilesortspu/WIN_NT/tilesortspu.dll] Error 2
> make[1]: *** [dep] Error 2
> make: *** [tilesort.subdir] Error 2
>  

[Chromium-dev] Break in build on Windows in tilesortspu (THREADSAFE on, amlost cvs state)

[Maciej D. <mdo...@po...>]

Printouts below. I used cvs state for build with one exception I took =
tilesortspu_pixels.c revision: 1.52 instead of latest  revision: 1.53. =
With revision 1.53 it is not compiling at all. With 1.52 it can be built =
with THREADSAFE =3D off but breaks with THREADSAFE =3D on (what I really =
need).

--=20
Best regards
Maciej

-------------------------------------------------------------------------=
------
              Building tilesortspu.dll for WIN_NT (DEBUG) (THREADSAFE) =
(STATE) (PACK)
-------------------------------------------------------------------------=
------
[...] [Compiling is ok]

Linking ../../built/tilesortspu/WIN_NT/tilesortspu.dll
   Creating library ../../built/tilesortspu/WIN_NT/tilesortspu.lib and =
object ..
/../built/tilesortspu/WIN_NT/tilesortspu.exp
tilesortspu_pixels.obj : error LNK2001: unresolved external symbol =
__PackerTSD
../../built/tilesortspu/WIN_NT/tilesortspu.dll : fatal error LNK1120: 1 =
unresolv
ed externals
make[2]: *** [../../built/tilesortspu/WIN_NT/tilesortspu.dll] Error 2
make[1]: *** [dep] Error 2
make: *** [tilesort.subdir] Error 2

Re: [Chromium-dev] Break in build on Windows in crdlm (THREADSAFE on, cvs state)

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

Maciej Donotek wrote:
> Print outs are attached below. Can it easily be fixed?

Looks like a few symbols were missing in the util.def file.  I've 
checked in the fix.

-Brian

[Chromium-dev] Break in build on Windows in crdlm (THREADSAFE on, cvs state)

[Maciej D. <mdo...@po...>]

Print outs are attached below. Can it easily be fixed?

-- 
Regards
Maciej Donotek

-------------------------------------------------------------------------------
              Building crdlm.dll for WIN_NT (DEBUG) (THREADSAFE)
-------------------------------------------------------------------------------
Making the DLM definitions file
Making the DLM functions header
python.exe dlm_generated.py headers > dlm_generated.h
python.exe dlm_generated.py source > dlm_generated.c
Rebuilding dependencies for dlm_generated.c
Rebuilding dependencies for dlm_calllist.c
Rebuilding dependencies for dlm_error.c
Rebuilding dependencies for dlm_checklist.c
Rebuilding dependencies for dlm_arrays.c
Rebuilding dependencies for dlm_pointers.c
Rebuilding dependencies for dlm_lists.c
Rebuilding dependencies for dlm.c
Compiling dlm.c
Compiling dlm_lists.c
Compiling dlm_generated.c
Compiling dlm_pointers.c
Compiling dlm_arrays.c
Compiling dlm_checklist.c
Compiling dlm_error.c
Compiling dlm_calllist.c
Linking ../built/crdlm/WIN_NT/crdlm.dll
   Creating library ../built/crdlm/WIN_NT/crdlm.lib and object 
../built/crdlm/WI
N_NT/crdlm.exp
dlm.obj : error LNK2001: unresolved external symbol _crInitTSDF
dlm.obj : error LNK2001: unresolved external symbol _crFreeTSD
dlm.obj : error LNK2001: unresolved external symbol _crFreeMutex
../built/crdlm/WIN_NT/crdlm.dll : fatal error LNK1120: 3 unresolved 
externals
make[1]: *** [../built/crdlm/WIN_NT/crdlm.dll] Error 2
make: *** [dep] Error 2 

[Chromium-dev] OSX or YDL?

[J.R. M. <JR...@jr...>]

Has anyone had successes with chromium on either OS X or YDL?  We are  
trying to decide if we can use an existing G5 cluster we have, or  
should invest in some PCs for a tiled display.

Thanks for the advice-
J.R.

[Chromium-dev] (no subject)

[Stefan L. <sli...@up...>]

I'm trying to run a driving simulator based on OpenSceneGraph and Cg in
stereo over Chromium. It works fine when i disable all Cg relevant code. =
But
as soon as i enable the shader programs the model that the shader would
affect disappears. Any idea what this could be? I also tested chromium =
with
the standard Cg demos and the vertprog_projection_param set but with the
same result. I couldn't see any shader effects with the tilesort SPU.=20
=20
My system:=20
Pentium 4
nvidia gefore 6800 Ultra
Debian Sarge with 2.6.8 Kernel
chromium from cvs
latest nvidia drivers
latest Cg Toolkit=20
=20
Any help is highly appreciated. Did anyone get the Cg Demos to run in
stereo? (It is mentioned in the Chromium docu, this makes me confident)
=20
Thanks
Stefan=20

-----------------------------------------------------------------

Stefan Lietsch

University of Paderborn
Paderborn Center for Parallel Computing
F=FCrstenallee 11
33102 Paderborn, Germany
=20
Office:  F0.337

Phone: +49 5251 60-6287
Fax:     +49 5251 60-6297
Email:   sli...@up...

-----------------------------------------------------------------=20

=20

[Chromium-dev] Re: [Chromium-users] cluster recommendations?

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

You might want to talk to the GraphStream and Tungsten Graphics folks 
since this is what they do, although often for larger configs.  If you 
just need to drive the displays, it will probably be cheaper (and 
perform better) to just run each T221 with a single PC and a Nvidia 
Quadro board (2 dvi-d connectors).

-Mike

J.R. Manes wrote:

>
> Howdy-
>
> We are getting two IBM 9 Megapixel flat panels and have about 10K to  
> spend on a cluster to drive them.  Does anyone have any  
> recommendations?  We were thinking of going with 4 PCs (2 PCs each  
> driving 2 tiles).
>
> Could someone recommend what they would purchase in this situation?
>
> Thanks,
> J.R.
> jr...@jr...
> University of Alaska Fairbanks
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle 
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing 
> & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Chromium-users mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-users

[Chromium-dev] cluster recommendations?

[J.R. M. <jr...@jr...>]

Howdy-

We are getting two IBM 9 Megapixel flat panels and have about 10K to  
spend on a cluster to drive them.  Does anyone have any  
recommendations?  We were thinking of going with 4 PCs (2 PCs each  
driving 2 tiles).

Could someone recommend what they would purchase in this situation?

Thanks,
J.R.
jr...@jr...
University of Alaska Fairbanks

[Chromium-dev] Multi-line options not allowed? file networking

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

Hi,

  Is there some reason multi-line values for options (of type CR_STRING) 
are not allowed?  My option-setting-callback-fn only receives the first 
line.


Also, is the 'file' network type working for people?
I had to change net.c:80 from
  if(!crStrcmp(protocol, file) ..
to
  if(!crStrncmp(protocol, file, 4) ..
in order to avoid messages like "invalid protocol: file://...".

I also had to call servernode.AddTile(..) to avoid getting a failure in 
the assertion at server_tiles.c:529.  (not given in playback.conf)


thanks!
Daniel Faken

[Chromium-dev] Re: SPU compile problem

[Í¢¿¡ Ñ. <yan...@ho...>]

I use the debug mode and fix the problem!
Thanks for help!

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

[Chromium-dev] Re: SPU compile problem

[Í¢¿¡ Ñ. <yan...@ho...>]

I use the debug mode and fix the problem!
Thanks for help!

_________________________________________________________________
Don’t just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/

Re: [Chromium-dev] SPU compile problem

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

That looks OK to me.  I don't know what the problem is.  Have you=20
tried compiling Chromium in debug mode?  You might get more info that=20
way (edit options.mk, set RELEASE=3D0).

-Brian

PS: I'm posting all follow-ups to the mailing list.


=CD=A2=BF=A1 =D1=EE wrote:
> I run the command "ldd libwarpvertexspu.so", the result is:
> [yzheng1@cesc12 Linux]$ ldd libwarpvertexspu.so
>        libCgGL.so =3D> /usr/lib/libCgGL.so (0x4001b000)
>        libCg.so =3D> /usr/lib/libCg.so (0x4005f000)
>        libspuload.so =3D>=20
> /u1/yzheng1/TiledDisplay/Chromium/lib/Linux/libspuload.so
> (0x4027b000)
>        libcrutil.so =3D>=20
> /u1/yzheng1/TiledDisplay/Chromium/lib/Linux/libcrutil.so (
> 0x402af000)
>        libcrmothership.so =3D>=20
> /u1/yzheng1/TiledDisplay/Chromium/lib/Linux/libcrmot
> hership.so (0x402cc000)
>        libstdc++.so.5 =3D> /usr/lib/libstdc++.so.5 (0x402d1000)
>        libm.so.6 =3D> /lib/tls/libm.so.6 (0x40384000)
>        libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x403a6000)
>        libc.so.6 =3D> /lib/tls/libc.so.6 (0x42000000)
>        libdl.so.2 =3D> /lib/libdl.so.2 (0x403ae000)
>        libpthread.so.0 =3D> /lib/tls/libpthread.so.0 (0x403b1000)
>        /lib/ld-linux.so.2 =3D> /lib/ld-linux.so.2 (0x80000000)
>=20
> It doesn't seem any problem, Could you tell me if it is right? Or if=20
> there is some question ,could you give me some help? Thanks a lot!
>=20
> Sincerely yours,
>   Yang Tingjun
>=20
>> From: Brian Paul <bri...@tu...>
>> To: =CD=A2=BF=A1 =D1=EE <yan...@ho...>
>> CC: chr...@li...
>> Subject: Re: [Chromium-dev] SPU compile problem
>> Date: Thu, 11 Aug 2005 08:23:26 -0600
>>
>> =CD=A2=BF=A1 =D1=EE wrote:
>>
>>>   I write a SPU called warpvertexspu to warp the image by a Cg=20
>>> program. In the warpvertexspu.h,
>>> I  include the cg.h and cgGL.h and in warpvertexspu_init.c and=20
>>> warpvertexspu.c I call cg and cgGL functions. But after I compile the=
=20
>>> source by adding -lCgGL and -lCg to the LDFLAGS variable in the=20
>>> makefile, when I use the warpvertexspu.so , It says "DLL could=20
>>> find/open the warpvertexspu.so". But if I comment the cg and cgGL=20
>>> functions in the warpvertexspu.c and keep the cg functions in the=20
>>> warpvertexspu_init.c, after compile the SPU can work well.
>>> the warpvertexspu.c:
>>>
>>> #include <stdio.h>
>>> #include "cr_spu.h"
>>> #include "warpvertexspu.h"
>>>
>>>
>>> static void WARPVERTEXSPU_APIENTRY warpvertexBegin(GLenum mode)
>>> {
>>>    if(WarpParam!=3DNULL)
>>>          cgGLSetMatrixParameterfc(WarpParam,WarpM);
>>>     if(ModelViewProjParam!=3DNULL)
>>>         cgGLSetStateMatrixParameter(ModelViewProjParam,
>>>                               CG_GL_MODELVIEW_PROJECTION_MATRIX,
>>>                               CG_GL_MATRIX_IDENTITY);
>>>     cgGLEnableProfile(profile);
>>>     warpvertex_spu.super.Begin(mode);
>>> }
>>>
>>> static void WARPVERTEXSPU_APIENTRY warpvertexEnd(void)
>>> {
>>>     warpvertex_spu.super.End();
>>>     cgGLDisableProfile(profile);
>>> }
>>> SPUNamedFunctionTable _cr_warpvertex_table[] =3D {
>>>       { "Begin",   (SPUGenericFunction)warpvertexBegin },
>>>       { "End",     (SPUGenericFunction)warpvertexEnd   },
>>>       { NULL, NULL }
>>> };
>>>
>>> I don't know why  calling cg functions in the warpvertexspu_int.c can=
=20
>>> work well but calling in the warpvertexspu.c cannot work. Maybe there=
=20
>>> is something wrong with the makefile.could you give me some help?
>>> Thanks very much!
>>
>>
>> Try running 'ldd libwarpvertex.so'.  There may be some unresolved=20
>> dependencies.
>>
>> -Brian
>>
>=20
> _________________________________________________________________
> Don=92t just search. Find. Check out the new MSN Search!=20
> http://search.msn.click-url.com/go/onm00200636ave/direct/01/
>=20

Re: [Chromium-dev] SPU compile problem

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

=CD=A2=BF=A1 =D1=EE wrote:
>   I write a SPU called warpvertexspu to warp the image by a Cg program.=
=20
> In the warpvertexspu.h,
> I  include the cg.h and cgGL.h and in warpvertexspu_init.c and=20
> warpvertexspu.c I call cg and cgGL functions. But after I compile the=20
> source by adding -lCgGL and -lCg to the LDFLAGS variable in the=20
> makefile, when I use the warpvertexspu.so , It says "DLL could find/ope=
n=20
> the warpvertexspu.so". But if I comment the cg and cgGL functions in th=
e=20
> warpvertexspu.c and keep the cg functions in the warpvertexspu_init.c,=20
> after compile the SPU can work well.
> the warpvertexspu.c:
>=20
> #include <stdio.h>
> #include "cr_spu.h"
> #include "warpvertexspu.h"
>=20
>=20
> static void WARPVERTEXSPU_APIENTRY warpvertexBegin(GLenum mode)
> {
>    if(WarpParam!=3DNULL)
>          cgGLSetMatrixParameterfc(WarpParam,WarpM);
>     if(ModelViewProjParam!=3DNULL)
>         cgGLSetStateMatrixParameter(ModelViewProjParam,
>                               CG_GL_MODELVIEW_PROJECTION_MATRIX,
>                               CG_GL_MATRIX_IDENTITY);
>     cgGLEnableProfile(profile);
>     warpvertex_spu.super.Begin(mode);
> }
>=20
> static void WARPVERTEXSPU_APIENTRY warpvertexEnd(void)
> {
>     warpvertex_spu.super.End();
>     cgGLDisableProfile(profile);
> }
> SPUNamedFunctionTable _cr_warpvertex_table[] =3D {
>       { "Begin",   (SPUGenericFunction)warpvertexBegin },
>       { "End",     (SPUGenericFunction)warpvertexEnd   },
>       { NULL, NULL }
> };
>=20
> I don't know why  calling cg functions in the warpvertexspu_int.c can=20
> work well but calling in the warpvertexspu.c cannot work. Maybe there i=
s=20
> something wrong with the makefile.could you give me some help?
> Thanks very much!

Try running 'ldd libwarpvertex.so'.  There may be some unresolved=20
dependencies.

-Brian

[Chromium-dev] SPU compile problem

[Í¢¿¡ Ñ. <yan...@ho...>]

   I write a SPU called warpvertexspu to warp the image by a Cg program. In 
the warpvertexspu.h,
I  include the cg.h and cgGL.h and in warpvertexspu_init.c and 
warpvertexspu.c I call cg and cgGL functions. But after I compile the source 
by adding -lCgGL and -lCg to the LDFLAGS variable in the makefile, when I 
use the warpvertexspu.so , It says "DLL could find/open the 
warpvertexspu.so". But if I comment the cg and cgGL functions in the 
warpvertexspu.c and keep the cg functions in the warpvertexspu_init.c, after 
compile the SPU can work well.
the warpvertexspu.c:

#include <stdio.h>
#include "cr_spu.h"
#include "warpvertexspu.h"


static void WARPVERTEXSPU_APIENTRY warpvertexBegin(GLenum mode)
{
    if(WarpParam!=NULL)
          cgGLSetMatrixParameterfc(WarpParam,WarpM);
     if(ModelViewProjParam!=NULL)
         cgGLSetStateMatrixParameter(ModelViewProjParam,
                               CG_GL_MODELVIEW_PROJECTION_MATRIX,
                               CG_GL_MATRIX_IDENTITY);
     cgGLEnableProfile(profile);
     warpvertex_spu.super.Begin(mode);
}

static void WARPVERTEXSPU_APIENTRY warpvertexEnd(void)
{
     warpvertex_spu.super.End();
     cgGLDisableProfile(profile);
}
SPUNamedFunctionTable _cr_warpvertex_table[] = {
       { "Begin",   (SPUGenericFunction)warpvertexBegin },
       { "End",     (SPUGenericFunction)warpvertexEnd   },
       { NULL, NULL }
};

I don't know why  calling cg functions in the warpvertexspu_int.c can work 
well but calling in the warpvertexspu.c cannot work. Maybe there is 
something wrong with the makefile.could you give me some help?
Thanks very much!

Sincerely yours
    Yang Tingjun

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar – get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

[Chromium-dev] [ANN] Alpha version of Scripting bindings to Chromium available

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

Hello,

  I've put up an early version of my Scheme scripting bindings for 
Chromium (chromium.sourceforge.net) at:
  http://www.cascv.brown.edu/~faken/sscriptedSPU-0.1a.tgz

The included README follows.

Comments, etc. are welcome (though I'll be on vacation until Aug 8th).

cheers,
Daniel Faken

---------------------------------------------------------------------
| README for Scheme-Scripted SPU  -  A.K.A. sscriptedspu
---------------------------------------------------------------------
Version: 0.1 (alpha) - July 31, 2005

This is a SPU (Stream-Processing Unit) for "Chromium" v1.8.
More information on Chromium is at http://chromium.sourceforge.net.

This SPU allows callbacks into Scheme, using the 'Chicken' scheme->C 
compiler.
More information on Chicken is at 
http://www.call-with-current-continuation.org.

----------------
LICENSE
----------------
This is released under the Lesser GNU Public License.


-----------------
INSTALLATION
-----------------
Chromium 1.8 and Chicken 2.0 are required to build this.

For Chicken, you should also have installed the 'debug' and 'opengl' eggs.

Once you have built chromium, move this directory to the 'spu' 
subdirectory of the chromium distribution, and type 'make'.

Then go into the 'scm_crif' ("scheme-chromium-interface") directory, make 
sure 'crhome' is a symlink to the top-level chromium directory, and run 
"chicken-setup chromium.setup".  This should build and install the support 
libraries used by the 'sscriptedSPU'.
  To remove the temporary files afterwards, run "chicken-setup 
chromium.setup clean".

To test, there is an example 'conf' file in the directory; run 'python 
sscripted.conf 10000 glxgears &' and then 'crappfaker'.  This will (by 
default) run 'print.scm' which will print out all OpenGL commands.
  There is also a file 'sputest.scm' in the scm_crif directory which is 
the equivalent of cr/spu/tester/sputest.c (provided here as 
orig-sputest.c), but in Scheme.  To run, execute 'csi sputest.scm' (with 
no mothership running).

I have only tested this with gcc, on Linux so far (FC3 and Kanotix 2005).


-----------------
USAGE
-----------------
Documentation is lacking right now.
  Please consult the example scripts: motionblur.scm & print.scm
- these are (fairly) equivalent to the SPUs of the same names that come
with chromium.

To execute code at startup, just set the 'startup_code' Chromium parameter 
for
this SPU to your desired Scheme code.
  By default it is something like '(load "print.scm")'.

You can set the environment variable SSCRIPTED_SPU_DEBUG_LEVEL to a 
positive
number to enable some verbose debugging info.
('10' is the highest effective setting)

There are several currently-not-full-functional pieces (which are not used 
in
the examples), namely
* this is designed to generate multiple, independent, 
simultaneously-functional scripted-spus.  See sscriptedspu.c's use of 
sscriptedspu-template.c.
  Currently only one copy is created/available.
* the [Get]ChromiumParameter*() API, which will allow access to the 
scripted-spu through the Chromium API.
* This is set up to use the "##sys#call-host" (for lack of a better name) 
FFI discussed at 
http://lists.gnu.org/archive/html/chicken-users/2005-07/msg00074.html.  
There are some features supporting the original/official (as of Chicken 
2.0) 'entry points' API, but they are not used.
* I've tried to structure things to be easily switcheable to another 
scripting language (indeed, I had a functioning TCL interface) - only 
sscriptedspu.c (& the files it includes & files generating those) is 
Chicken/Scheme dependent.
* a few other things scattered about.


----------------
ACKNOWLEDGEMENTS
----------------
Thanks to Felix Winkelmann, the creator of 'Chicken', for his helpfulness 
and responsiveness, as well as for Chicken itself.

And, of course, thanks to the developers of Chromium.

The code in sscripted/scm_crif/generate_glenum_strings.py is taken from 
the original "print SPU".

----------------
AUTHOR
----------------
Daniel B. Faken
email: Daniel_Faken -at- brown.edu

Some of this work was funded by grants from the U.S. Department of Energy.