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

[Chromium-dev] network layer clean-ups

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

I've been doing some work in the network layer, mostly cleaning up the 
code, adding new comments, etc.  I'm 99% sure I haven't broken 
anything in the non-TCP/IP protocols, but people might want to 
double-check that.

-Brian

[Chromium-dev] SIGGRAPH BOF information

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

I've signed us up for tomorrow, August 11th, from 4-5pm.  I believe we 
are in room 504, but you can check the sign next to the BOF rooms.

It would be if all of the Chromium users at SIGGRAPH could stop by and 
we could catch up on what everyone is working on and what current issues 
are.  We have no formal agenda, so come with your own. ;-)

Thanks!

-Mike

Re: [Chromium-dev] readback + tilesort

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

Johann Won wrote:
> Hi,
> 
> Putting readback + tilesort aside, I'm testing binaryswap + tilesort
> configuration.
> 
> With the patch, the problem mentioned earlier has been (partially) resolved.
> However this time, similar symtpom is found with bswap + tilesort.
> The same portion is drawn on each of the tiles ( I applied the patch ).
> 
> Attached .conf is a modified version of psubmit_bswap, which uses two tiles.
> Please test with it, and give me a comment.

Johann,

Try applying the attached patch in the crserverlib/ directory.  I 
think this'll fix your problems.

-Brian

[Chromium-dev] seethrough SPU and documents

[Anthony S. <A....@cs...>]

I've been lurking on this list for a while - we've been using Chromium 
for a while for some demos and prototyping some systems for driving a CAVE.

Because of the experience of a student, I took a look at the online 
documentation. The online and CVS documentation for the seethrough 
example is out of date (the state tracker code was wrong, some code 
typos). I had a go at updating it and it almost works as advertised now.

First things first: in template/gen_template.py, the file 
templatespu_proto.py doesn't exist, so the generation scripts fails. 
That line needs deleting.

In the seethrough example, I fixed all the problems with changed data 
structures and code, but I can't get my quake3 to look like glassquake 
unless I force multitexturing to be off. I.E. in q3config.cfg, change:

  seta r_ext_multitexture "1"
to
  seta r_ext_multitexture "0"

I had a quick go at getting the multitexturing working, but someone who 
knows more about chromium could probably spot the problem straight away. 
Otherwise it works fine.

As I'm not registered as a developer on sourceforge, I put a revised 
version of the codegen.html here:
  http://www.cs.ucl.ac.uk/staff/A.Steed/scratch/cr/codegen.html
and code packages here:
  http://www.cs.ucl.ac.uk/staff/A.Steed/scratch/cr/seethrough.tar.gz
  http://www.cs.ucl.ac.uk/staff/A.Steed/scratch/cr/seethrough_step11.tar.gz


Anthony

Re: [Chromium-dev] readback + tilesort

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

Actually, binaryswap already uses the WindowPos version.  Brian must of 
caught that when the readback spu was patched.  So, somehow the raster 
position is not being setup correctly during interaction of the 
binaryswap SPU and the tilesort SPU.

-Mike

Mike Houston wrote:
> I'm guessing the issue is how binaryswap sets raster position.  If you 
> look at the client draw pixels call in binaryswap, I think you will 
> still see a call to glRasterPos.  You need to change this call stack 
> here to look like the readbackspu's client draw pixels.
> 
> -Mike
> 
> Johann Won wrote:
> 
>> Hi,
>>
>> Putting readback + tilesort aside, I'm testing binaryswap + tilesort
>> configuration.
>>
>> With the patch, the problem mentioned earlier has been (partially) 
>> resolved.
>> However this time, similar symtpom is found with bswap + tilesort.
>> The same portion is drawn on each of the tiles ( I applied the patch ).
>>
>> Attached .conf is a modified version of psubmit_bswap, which uses two 
>> tiles.
>> Please test with it, and give me a comment.
>>
>> Thanks in advance,
>>
>> - johann.
>>
>>
>> Quoting Brian Paul <bri...@tu...>:
>>
>>
>>> Joong Ho (Johann) Won wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm testing a combination of readback and tilesort SPUs, of which the
>>>> ultimate purpose is to let sort-last parallel apps be able to render on
>>>
>>>
>>> a
>>>
>>>> DMX mural display. I wrote a simple test script for the first step,
>>>
>>>
>>> which is
>>>
>>>> a very simple modification of simplemural.conf.
>>>> Simplemural.conf uses a tilesort SPU to render an app in two seperate
>>>> (possibly remote) windows.
>>>> My intension is just to add a readback SPU on top of the tilesort SPU.
>>>
>>>
>>> At
>>>
>>>> this stage, it has nothing to do with DMX.
>>>>
>>>> What should be rendered must be the same as that of the original
>>>> simplemural.conf, but it is not.
>>>> SAME part of the application window is rendered on both of the
>>>
>>>
>>> crserver
>>>
>>>> windows, i.e. the left half.
>>>>
>>>> Configuration for readback is the simplest, as will be shown below.
>>>> Mike Houston's guess is that there may be a bug in arguments for
>>>
>>>
>>> DrawPixels.
>>>
>>>> Even worse is that when the 'extract_depth' option is turned on,
>>>
>>>
>>> nothing is
>>>
>>>> drawn at all.
>>>>
>>>> Below is my modified simplemural.conf script. Only a few lines related
>>>
>>>
>>> with
>>>
>>>> readbackSPU are added and without these, everything works fine.
>>>>
>>>> Thanks in advance for any comment.
>>>
>>>
>>> I found the problem.  On the server side, the initial current raster 
>>> position needs to be translated by the origin of the server's tile. 
>>> Normally, the first call to glRasterPos/glWindowPos would set it 
>>> correctly, but the tilesort SPU's state tracker was filtering out 
>>> that state change.
>>>
>>> Try applying this patch to crserverlib/server_context.c
>>>
>>> -Brian
>>>
>>>
>>
>>
>>
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev

Re: [Chromium-dev] readback + tilesort

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

I'm guessing the issue is how binaryswap sets raster position.  If you 
look at the client draw pixels call in binaryswap, I think you will 
still see a call to glRasterPos.  You need to change this call stack 
here to look like the readbackspu's client draw pixels.

-Mike

Johann Won wrote:

> Hi,
> 
> Putting readback + tilesort aside, I'm testing binaryswap + tilesort
> configuration.
> 
> With the patch, the problem mentioned earlier has been (partially) resolved.
> However this time, similar symtpom is found with bswap + tilesort.
> The same portion is drawn on each of the tiles ( I applied the patch ).
> 
> Attached .conf is a modified version of psubmit_bswap, which uses two tiles.
> Please test with it, and give me a comment.
> 
> Thanks in advance,
> 
> - johann.
> 
> 
> Quoting Brian Paul <bri...@tu...>:
> 
> 
>>Joong Ho (Johann) Won wrote:
>>
>>>Hi,
>>>
>>>I'm testing a combination of readback and tilesort SPUs, of which the
>>>ultimate purpose is to let sort-last parallel apps be able to render on
>>
>>a
>>
>>>DMX mural display. I wrote a simple test script for the first step,
>>
>>which is
>>
>>>a very simple modification of simplemural.conf.
>>>Simplemural.conf uses a tilesort SPU to render an app in two seperate
>>>(possibly remote) windows.
>>>My intension is just to add a readback SPU on top of the tilesort SPU.
>>
>>At
>>
>>>this stage, it has nothing to do with DMX.
>>>
>>>What should be rendered must be the same as that of the original
>>>simplemural.conf, but it is not.
>>>SAME part of the application window is rendered on both of the
>>
>>crserver
>>
>>>windows, i.e. the left half.
>>>
>>>Configuration for readback is the simplest, as will be shown below.
>>>Mike Houston's guess is that there may be a bug in arguments for
>>
>>DrawPixels.
>>
>>>Even worse is that when the 'extract_depth' option is turned on,
>>
>>nothing is
>>
>>>drawn at all.
>>>
>>>Below is my modified simplemural.conf script. Only a few lines related
>>
>>with
>>
>>>readbackSPU are added and without these, everything works fine.
>>>
>>>Thanks in advance for any comment.
>>
>>I found the problem.  On the server side, the initial current raster 
>>position needs to be translated by the origin of the server's tile. 
>>Normally, the first call to glRasterPos/glWindowPos would set it 
>>correctly, but the tilesort SPU's state tracker was filtering out that 
>>state change.
>>
>>Try applying this patch to crserverlib/server_context.c
>>
>>-Brian
>>
>>
> 
> 
> 

Re: [Chromium-dev] readback + tilesort

[Johann W. <jh...@st...>]

Hi,

Putting readback + tilesort aside, I'm testing binaryswap + tilesort
configuration.

With the patch, the problem mentioned earlier has been (partially) resolved.
However this time, similar symtpom is found with bswap + tilesort.
The same portion is drawn on each of the tiles ( I applied the patch ).

Attached .conf is a modified version of psubmit_bswap, which uses two tiles.
Please test with it, and give me a comment.

Thanks in advance,

- johann.


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

> Joong Ho (Johann) Won wrote:
> > Hi,
> > 
> > I'm testing a combination of readback and tilesort SPUs, of which the
> > ultimate purpose is to let sort-last parallel apps be able to render on
> a
> > DMX mural display. I wrote a simple test script for the first step,
> which is
> > a very simple modification of simplemural.conf.
> > Simplemural.conf uses a tilesort SPU to render an app in two seperate
> > (possibly remote) windows.
> > My intension is just to add a readback SPU on top of the tilesort SPU.
> At
> > this stage, it has nothing to do with DMX.
> > 
> > What should be rendered must be the same as that of the original
> > simplemural.conf, but it is not.
> > SAME part of the application window is rendered on both of the
> crserver
> > windows, i.e. the left half.
> > 
> > Configuration for readback is the simplest, as will be shown below.
> > Mike Houston's guess is that there may be a bug in arguments for
> DrawPixels.
> > Even worse is that when the 'extract_depth' option is turned on,
> nothing is
> > drawn at all.
> > 
> > Below is my modified simplemural.conf script. Only a few lines related
> with
> > readbackSPU are added and without these, everything works fine.
> > 
> > Thanks in advance for any comment.
> 
> I found the problem.  On the server side, the initial current raster 
> position needs to be translated by the origin of the server's tile. 
> Normally, the first call to glRasterPos/glWindowPos would set it 
> correctly, but the tilesort SPU's state tracker was filtering out that 
> state change.
> 
> Try applying this patch to crserverlib/server_context.c
> 
> -Brian
> 
> 

Re: [Chromium-users] Re: [Chromium-dev] Who's going to be at SIGGRAPH?

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

We can do a more formal one at Viz if people prefer.  I'm already doing 
a workshop on parallel rendering at Vis again this year, which we will 
announce shortly, so I'm not sure if we need something separate at Vis.

I mainly just thought that if enough people are going to be at SIGGRAPH, 
we might have enough mass to do a BOF there.

-Mike

Volz, Bill (WRVO) (Bill.Volz) wrote:

> Might Vis 2004 be better for a BoF? More time to organize it. It's the
> week of Oct 11.
> 
> William R Volz,  Senior Research Geophysicist
> 
> ChevronTexaco 
> Energy Technology Company
> Subsurface Characterization Business Line
> Interpretation Product Development & Support
> 4800 Fournace Place, Bellaire, TX, 77401
> Tel 713 432 6666  Fax 713 432 2536
> 
> 
>><mailto:bil...@ch...>
>>This message may contain confidential information that is proprietary
> 
> to ChevronTexaco and is intended only for the use of the parties to whom
> it is addressed. If you are not an intended recipient, you are hereby
> notified that any disclosure, copying, distribution or use of any
> information in this message is strictly prohibited. If you have received
> this message in error, please notify me immediately at the telephone
> number noted above.
> 
> 
> 
>>-----Original Message-----
>>From: chr...@li... 
>>[mailto:chr...@li...] On Behalf 
>>Of Jens Owen
>>Sent: Tuesday, August 03, 2004 1:51 PM
>>To: Mike Houston
>>Cc: Chromium-users; chr...@li...
>>Subject: [Chromium-users] Re: [Chromium-dev] Who's going to be 
>>at SIGGRAPH?
>>
>>
>>Mike Houston wrote:
>>
>>>How many people are going to be at SIGGRAPH?  Is there interest in
>>>having a BOF?  Or should we just get together informally if 
>>
>>people want 
>>
>>>to talk about various things?
>>
>>Mike,
>>
>>From Tungsten Graphics, Robert Ellison, Ken Mulcahy and 
>>myself will be 
>>at SigGraph.  Unfortunately, Brian Paul and Alan Hourihane will not be 
>>able to attend this year.
>>
>>-- 
>>                               /\
>>         Jens Owen            /  \/\ _
>>  je...@tu...  /    \ \ \   Steamboat Springs, Colorado
>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by OSTG. Have you noticed the 
>>changes on Linux.com, ITManagersJournal and NewsForge in the 
>>past few weeks? Now, one more big change to announce. We are 
>>now OSTG- Open Source Technology Group. Come see the changes 
>>on the new OSTG site. www.ostg.com 
>>_______________________________________________
>>Chromium-users mailing list Chr...@li...
>>https://lists.sourceforge.net/lists/listinfo/chromium-users
>>
>>
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Chromium-users mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-users

Re: [Chromium-dev] Who's going to be at SIGGRAPH?

[Jens O. <je...@tu...>]

Mike Houston wrote:
> How many people are going to be at SIGGRAPH?  Is there interest in 
> having a BOF?  Or should we just get together informally if people want 
> to talk about various things?

Mike,

 From Tungsten Graphics, Robert Ellison, Ken Mulcahy and myself will be 
at SigGraph.  Unfortunately, Brian Paul and Alan Hourihane will not be 
able to attend this year.

-- 
                                /\
          Jens Owen            /  \/\ _
   je...@tu...  /    \ \ \   Steamboat Springs, Colorado

[Chromium-dev] Re: Who's going to be at SIGGRAPH?

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

Mike Houston wrote:
> How many people are going to be at SIGGRAPH?  Is there interest in
> having a BOF?  Or should we just get together informally if people
> want to talk about various things?

I'll be there.  Randy will not be, I don't believe.

A BoF would probably be more interesting than an informal get-together,
as it would also attract the interest of other third parties.  However,
it's probably too late to organize anything "formal" through Siggraph.

-Sean

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

[Chromium-dev] Who's going to be at SIGGRAPH?

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

How many people are going to be at SIGGRAPH?  Is there interest in 
having a BOF?  Or should we just get together informally if people want 
to talk about various things?

-Mike

Re: [Chromium-dev] CRUT and Darwin

[Alan M. <al...@re...>]

On Fri, 2004-07-30 at 15:26, Christopher Waters wrote:
> Would it be possible for someone to commit this to the CVS?  Perhaps 
> with the fix I suggested to David Jones, as well.
> 
Send it to me and I'll put it in.

>   -Chris Waters
> 
> On Jul 29, 2004, at 12:32 PM, Christopher Waters wrote:
> 
> > and here is said patch, along with renderspu_agl.c :)
> >
> >  -Chris
> >
> > <darwin_patch.tar.gz>
> >
> > On Jul 28, 2004, at 4:28 PM, Christopher Waters wrote:
> >
> >> While I'm on the topic of Darwin, last week I made a patch to update 
> >> to 'full' CGL/AGL (faker/render) support in Darwin, but apparently 
> >> 43k is too big of a file to send to the mailing list. =\  I'll most 
> >> likely flesh-out and send an updated patch later this week.
> >>
> >>  -Chris Waters
> >>
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev
-- 
Alan Matsuoka
Global Professional Services
Red Hat Canada, Ltd
mailto:al...@re...

Re: [Chromium-dev] CRUT and Darwin

[Christopher W. <cr...@ms...>]

Would it be possible for someone to commit this to the CVS?  Perhaps 
with the fix I suggested to David Jones, as well.

  -Chris Waters

On Jul 29, 2004, at 12:32 PM, Christopher Waters wrote:

> and here is said patch, along with renderspu_agl.c :)
>
>  -Chris
>
> <darwin_patch.tar.gz>
>
> On Jul 28, 2004, at 4:28 PM, Christopher Waters wrote:
>
>> While I'm on the topic of Darwin, last week I made a patch to update 
>> to 'full' CGL/AGL (faker/render) support in Darwin, but apparently 
>> 43k is too big of a file to send to the mailing list. =\  I'll most 
>> likely flesh-out and send an updated patch later this week.
>>
>>  -Chris Waters
>>

Re: [Chromium-dev] CRUT and Darwin

[Christopher W. <cr...@ms...>]

Ah, I do apologize for that.  I'm not aware of any way to retrieve the 
exact lib path, and NSCreateObjectFileImageFromFile apparantly needs 
the absolute path of the bundle.  Perhaps you could set an environment 
variable to the path, and change that code to something like this:

if( filename[0] != '/' ) {
	/* default to a chromium bundle */
	char path = crGetenv("CR_LIBRARY_PATH"); /* is there already a var for 
this? */
	crStrcpy( _filename, (path ? path : "/cr/lib/Darwin/") );
	crStrcat( _filename, filename );
} else {
	crStrcpy( _filename, filename );
}

  -Chris

On Jul 29, 2004, at 4:26 PM, David Jones wrote:

> Ok, now I can start it, but LoadBundle seems to be failing now.
>
> In dll.c, is this correct:
>
>> if( filename[0] != '/' ) {
>>                /* default to a chromium bundle */
>>                crStrcpy( _filename, "/cr/lib/Darwin/" );
>>                crStrcat( _filename, filename );
>>        } else {
>>                crStrcpy( _filename, filename );
>>        }
>
> The filename being passed is 'renderspu.bundle'.  After the cpy/cat
> operations, it tries opening the bundle at
> '/cr/lib/Darwin/renderspu.bundle'
>
> I think this only works if I install chromium at root level.  I'm 
> using a
> copy in my home directory.
>
> -Dave
>
>
> On Thu, 29 Jul 2004, Christopher Waters wrote:
>
>> add your chromium lib path to the environment variable
>> "DYLD_FALLBACK_LIBRARY_PATH"
>>
>> that should remedy it :)
>>
>>   -Chris
>>
>> On Jul 29, 2004, at 4:01 PM, David Jones wrote:
>>
>>> I'm having the same linking problem as before with the darwin builds.
>>> Running crserver gives me:
>>>
>>> vibrio% crserver
>>> dyld: crserver can't open library:
>>> ..//built/spuload/Darwin/libspuload.dylib  (No such file or 
>>> directory,
>>> errno = 2)
>>> zsh: trace trap  crserver
>>>
>>> And doing an 'otool -L' on crserver gives me:
>>>
>>> crserver:
>>>         ..//built/spuload/Darwin/libspuload.dylib (compatibility
>>> version 0.0.0, current version 0.0.0)
>>>         ../../built/crmothership/Darwin/libcrmothership.dylib
>>> (compatibility version 0.0.0, current version 0.0.0)
>>>         ../built/crpacker/Darwin/libcrpacker.dylib (compatibility
>>> version 0.0.0, current version 0.0.0)
>>>         ../built/crutil/Darwin/libcrutil.dylib (compatibility version
>>> 0.0.0, current version 0.0.0)
>>>         ../built/crunpacker/Darwin/libcrserver_crunpacker_copy.dylib
>>> (compatibility version 0.0.0, current version 0.0.0)
>>>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
>>> current version 71.1.1)
>>>
>>> Again, the cr binaries are not using absolute paths during linking
>>> which
>>> is giving me errors.
>>>
>>> -Dave
>>>
>>>
>>> On Thu, 29 Jul 2004, Christopher Waters wrote:
>>>
>>>> and here is said patch, along with renderspu_agl.c :)
>>>>
>>>>   -Chris
>>>>
>>>>
>>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by OSTG. Have you noticed the changes 
>> on
>> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
>> one more big change to announce. We are now OSTG- Open Source 
>> Technology
>> Group. Come see the changes on the new OSTG site. www.ostg.com
>> _______________________________________________
>> Chromium-dev mailing list
>> Chr...@li...
>> https://lists.sourceforge.net/lists/listinfo/chromium-dev
>>
>>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source 
> Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev
>

Re: [Chromium-dev] CRUT and Darwin

[David J. <jo...@mc...>]

Ok, now I can start it, but LoadBundle seems to be failing now.

In dll.c, is this correct:

>if( filename[0] != '/' ) {
>                /* default to a chromium bundle */
>                crStrcpy( _filename, "/cr/lib/Darwin/" );
>                crStrcat( _filename, filename );
>        } else {
>                crStrcpy( _filename, filename );
>        }

The filename being passed is 'renderspu.bundle'.  After the cpy/cat 
operations, it tries opening the bundle at 
'/cr/lib/Darwin/renderspu.bundle'

I think this only works if I install chromium at root level.  I'm using a 
copy in my home directory.

-Dave


On Thu, 29 Jul 2004, Christopher Waters wrote:

> add your chromium lib path to the environment variable 
> "DYLD_FALLBACK_LIBRARY_PATH"
> 
> that should remedy it :)
> 
>   -Chris
> 
> On Jul 29, 2004, at 4:01 PM, David Jones wrote:
> 
> > I'm having the same linking problem as before with the darwin builds.
> > Running crserver gives me:
> >
> > vibrio% crserver
> > dyld: crserver can't open library:
> > ..//built/spuload/Darwin/libspuload.dylib  (No such file or directory, 
> > errno = 2)
> > zsh: trace trap  crserver
> >
> > And doing an 'otool -L' on crserver gives me:
> >
> > crserver:
> >         ..//built/spuload/Darwin/libspuload.dylib (compatibility 
> > version 0.0.0, current version 0.0.0)
> >         ../../built/crmothership/Darwin/libcrmothership.dylib 
> > (compatibility version 0.0.0, current version 0.0.0)
> >         ../built/crpacker/Darwin/libcrpacker.dylib (compatibility 
> > version 0.0.0, current version 0.0.0)
> >         ../built/crutil/Darwin/libcrutil.dylib (compatibility version 
> > 0.0.0, current version 0.0.0)
> >         ../built/crunpacker/Darwin/libcrserver_crunpacker_copy.dylib 
> > (compatibility version 0.0.0, current version 0.0.0)
> >         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, 
> > current version 71.1.1)
> >
> > Again, the cr binaries are not using absolute paths during linking 
> > which
> > is giving me errors.
> >
> > -Dave
> >
> >
> > On Thu, 29 Jul 2004, Christopher Waters wrote:
> >
> >> and here is said patch, along with renderspu_agl.c :)
> >>
> >>   -Chris
> >>
> >>
> >
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev
> 
> 

Re: [Chromium-dev] CRUT and Darwin

[Christopher W. <cr...@ms...>]

add your chromium lib path to the environment variable 
"DYLD_FALLBACK_LIBRARY_PATH"

that should remedy it :)

  -Chris

On Jul 29, 2004, at 4:01 PM, David Jones wrote:

> I'm having the same linking problem as before with the darwin builds.
> Running crserver gives me:
>
> vibrio% crserver
> dyld: crserver can't open library:
> ..//built/spuload/Darwin/libspuload.dylib  (No such file or directory, 
> errno = 2)
> zsh: trace trap  crserver
>
> And doing an 'otool -L' on crserver gives me:
>
> crserver:
>         ..//built/spuload/Darwin/libspuload.dylib (compatibility 
> version 0.0.0, current version 0.0.0)
>         ../../built/crmothership/Darwin/libcrmothership.dylib 
> (compatibility version 0.0.0, current version 0.0.0)
>         ../built/crpacker/Darwin/libcrpacker.dylib (compatibility 
> version 0.0.0, current version 0.0.0)
>         ../built/crutil/Darwin/libcrutil.dylib (compatibility version 
> 0.0.0, current version 0.0.0)
>         ../built/crunpacker/Darwin/libcrserver_crunpacker_copy.dylib 
> (compatibility version 0.0.0, current version 0.0.0)
>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, 
> current version 71.1.1)
>
> Again, the cr binaries are not using absolute paths during linking 
> which
> is giving me errors.
>
> -Dave
>
>
> On Thu, 29 Jul 2004, Christopher Waters wrote:
>
>> and here is said patch, along with renderspu_agl.c :)
>>
>>   -Chris
>>
>>
>

Re: [Chromium-dev] CRUT and Darwin

[David J. <jo...@mc...>]

I'm having the same linking problem as before with the darwin builds.  
Running crserver gives me:

vibrio% crserver
dyld: crserver can't open library: 
..//built/spuload/Darwin/libspuload.dylib  (No such file or directory, errno = 2)
zsh: trace trap  crserver

And doing an 'otool -L' on crserver gives me:

crserver:
        ..//built/spuload/Darwin/libspuload.dylib (compatibility version 0.0.0, current version 0.0.0)
        ../../built/crmothership/Darwin/libcrmothership.dylib (compatibility version 0.0.0, current version 0.0.0)
        ../built/crpacker/Darwin/libcrpacker.dylib (compatibility version 0.0.0, current version 0.0.0)
        ../built/crutil/Darwin/libcrutil.dylib (compatibility version 0.0.0, current version 0.0.0)
        ../built/crunpacker/Darwin/libcrserver_crunpacker_copy.dylib (compatibility version 0.0.0, current version 0.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 71.1.1)

Again, the cr binaries are not using absolute paths during linking which 
is giving me errors.

-Dave


On Thu, 29 Jul 2004, Christopher Waters wrote:

> and here is said patch, along with renderspu_agl.c :)
> 
>   -Chris
> 
> 

Re: [Chromium-dev] CRUT and Darwin

[Christopher W. <cr...@ms...>]

and here is said patch, along with renderspu_agl.c :)

  -Chris

[Chromium-dev] Re: [Xorg] Chromium vs GLX protocol

[Keith W. <ke...@tu...>]

Adam Jackson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Thursday 29 July 2004 11:17, Alex Deucher wrote:
> 
>>couldn't chromium be merged into xorg someday to provide multi-head
>>open GL in conjunction with dmx on the same box or different boxes?
>>Say you have two 3d cards each could be brought up as independant X
>>servers with their own instances of the DRI.  Then chromium and DMX
>>could provide the middle layer so that multi-card hw Open GL would
>>just work for a xinerama desktop.
> 
> 
> Heh.  It won't be hardware-accelerated until we ditch GLcore for *_dri.so in 
> the server.  DMX just uses whatever indirect rendering path the server 
> provides.  There's a reason this is on my todo list ;)

Chromium provides accelerated rendering over the network, but the current 
interfaces are designed to support all manner of complex setups and don't have 
the convenience of things like "DISPLAY=thathost:0 glxgears".

Keith

[Chromium-dev] Re: [Xorg] Chromium vs GLX protocol

[Jens O. <je...@tu...>]

Brian Paul wrote:
> Jon Smirl wrote:
> 
>> Slashdot is saying that SGI is going to port their clustered ATI
>> graphics to Linux in the near future. The SGI page says this code is
>> based on Chromium. I've read that the network protocol of Chromium is
>> far better than the GLX protocol, especially in the area of state
>> management. Does anyone have experience with both protocols and can
>> comment on how they compare?
> 
> 
> Sure...
> 
>> If the Chromium protocol really is a lot better would it make sense to
>> evaluate shifting our focus from GLX to the Chromium protocol? In the
>> long  run the coming shift to things like X on GL and Glitz may
>> ultimately move a lot of network traffic from the X protocol to one of
>> the GL ones. If Chromium is significantly better wouldn't it be wiser
>> to change the X server GL protocol now rather than later?
> 
> 
> The Chromium command packer packs GL commands more densely than GLX. A 
> one-byte opcode is used for most commands and operands are packed 
> tightly in memory.  Opcodes are packed separate from the operands in a 
> unique way too.
> 
> Chromium also has a state tracking system which can eliminate redundant 
> commands from being packed/sent.  It's pretty complicated though and 
> still a source of bugs.
> 
> I wouldn't say that Chromium's packer is a *lot* better than GLX.  And I 
> wouldn't advocate switching to it.  GLX interoperability is important 
> and making such a switch would upset that.  I don't think the effort to 
> switch would be worth the trouble.  Performance-wise, I think the gains 
> would be quite modest.

Brian,

How about supporting key pieces of Chromium in the X.org release in 
addition to GLX?  Could integrating OpenGL API redirection, for example, 
make for a cleaner solution than what Chromium does with "app faker" today?

-- 
                                /\
          Jens Owen            /  \/\ _
   je...@tu...  /    \ \ \   Steamboat Springs, Colorado

RE: [Chromium-dev] readback + tilesort

[Joong Ho \(Johann\) W. <jh...@st...>]

(For dmx-devel subscribers, please refer to the included quotes to know the
history.)

The patch worked. Thanks Brian!
Now I'm trying to move on to DMX.
It somehow renders to the application window, but I doubt if it's working
correctly.
Below is the current configuration:

DMX setup: 1x2 horizontal wall
Test script : modified autodmx.conf
Test app : atlantis

When the window crosses the border, the same portion is rendered to both
displays. It is much like the previous symptom without DMX, but in this case
tile size can be asymmetric.
Most of all, in the crserver debug log, nothing is reported about the tile
size info.
In conventional DMX+CR setup (e.g. autodmx.conf + .crconfig), the log is
updated whenever the window crosses the border.

I attach the test .conf file which I use.
Since it is derived from autodmx.conf, I hope it can be used without
modification on usual DMX configuration.

Thanks in advance.

- johann.

-----Original Message-----
From: Brian Paul [mailto:bri...@tu...]
Sent: Wednesday, July 28, 2004 2:57 PM
To: Joong Ho (Johann) Won
Cc: chr...@li...
Subject: Re: [Chromium-dev] readback + tilesort


Joong Ho (Johann) Won wrote:
> Hi,
>
> I'm testing a combination of readback and tilesort SPUs, of which the
> ultimate purpose is to let sort-last parallel apps be able to render on a
> DMX mural display. I wrote a simple test script for the first step, which
is
> a very simple modification of simplemural.conf.
> Simplemural.conf uses a tilesort SPU to render an app in two seperate
> (possibly remote) windows.
> My intension is just to add a readback SPU on top of the tilesort SPU. At
> this stage, it has nothing to do with DMX.
>
> What should be rendered must be the same as that of the original
> simplemural.conf, but it is not.
> SAME part of the application window is rendered on both of the crserver
> windows, i.e. the left half.
>
> Configuration for readback is the simplest, as will be shown below.
> Mike Houston's guess is that there may be a bug in arguments for
DrawPixels.
> Even worse is that when the 'extract_depth' option is turned on, nothing
is
> drawn at all.
>
> Below is my modified simplemural.conf script. Only a few lines related
with
> readbackSPU are added and without these, everything works fine.
>
> Thanks in advance for any comment.

I found the problem.  On the server side, the initial current raster
position needs to be translated by the origin of the server's tile.
Normally, the first call to glRasterPos/glWindowPos would set it
correctly, but the tilesort SPU's state tracker was filtering out that
state change.

Try applying this patch to crserverlib/server_context.c

-Brian

[Chromium-dev] Re: [Xorg] Chromium vs GLX protocol

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

Jon Smirl wrote:
> Slashdot is saying that SGI is going to port their clustered ATI
> graphics to Linux in the near future. The SGI page says this code is
> based on Chromium. I've read that the network protocol of Chromium is
> far better than the GLX protocol, especially in the area of state
> management. Does anyone have experience with both protocols and can
> comment on how they compare?

Sure...

> If the Chromium protocol really is a lot better would it make sense to
> evaluate shifting our focus from GLX to the Chromium protocol? In the
> long  run the coming shift to things like X on GL and Glitz may
> ultimately move a lot of network traffic from the X protocol to one of
> the GL ones. If Chromium is significantly better wouldn't it be wiser
> to change the X server GL protocol now rather than later?

The Chromium command packer packs GL commands more densely than GLX. 
A one-byte opcode is used for most commands and operands are packed 
tightly in memory.  Opcodes are packed separate from the operands in a 
unique way too.

Chromium also has a state tracking system which can eliminate 
redundant commands from being packed/sent.  It's pretty complicated 
though and still a source of bugs.

I wouldn't say that Chromium's packer is a *lot* better than GLX.  And 
I wouldn't advocate switching to it.  GLX interoperability is 
important and making such a switch would upset that.  I don't think 
the effort to switch would be worth the trouble.  Performance-wise, I 
think the gains would be quite modest.

-Brian

Re: [Chromium-dev] CRUT and Darwin

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

I'm the moderator, but I get SO MANY moderator requests that I just
ignore them all.

On Wed, 28 Jul 2004 15:19:27 -0700, Jorge Luis Williams <jo...@jl...> wrote:
> 
> On Jul 28, 2004, at 2:28 PM, Christopher Waters wrote:
> 
> > While I'm on the topic of Darwin, last week I made a patch to update
> > to 'full' CGL/AGL (faker/render) support in Darwin, but apparently 43k
> > is too big of a file to send to the mailing list. =\  I'll most likely
> > flesh-out and send an updated patch later this week.
> 
> 
> I've had similar problems sending patches to this mailing list.  I get
> a notice stating that my msg is waiting for moderator approval, but
> this never happens. My final solution was simply to gzip the patch.
> Who's the moderator?
> 
> jOrGe W.
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev
> 
> 


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

Re: [Chromium-dev] CRUT and Darwin

[Jorge L. W. <jo...@jl...>]

On Jul 28, 2004, at 2:28 PM, Christopher Waters wrote:

> While I'm on the topic of Darwin, last week I made a patch to update 
> to 'full' CGL/AGL (faker/render) support in Darwin, but apparently 43k 
> is too big of a file to send to the mailing list. =\  I'll most likely 
> flesh-out and send an updated patch later this week.


I've had similar problems sending patches to this mailing list.  I get 
a notice stating that my msg is waiting for moderator approval, but 
this never happens. My final solution was simply to gzip the patch.  
Who's the moderator?

jOrGe W.

Re: [Chromium-dev] readback + tilesort

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

Joong Ho (Johann) Won wrote:
> Hi,
> 
> I'm testing a combination of readback and tilesort SPUs, of which the
> ultimate purpose is to let sort-last parallel apps be able to render on a
> DMX mural display. I wrote a simple test script for the first step, which is
> a very simple modification of simplemural.conf.
> Simplemural.conf uses a tilesort SPU to render an app in two seperate
> (possibly remote) windows.
> My intension is just to add a readback SPU on top of the tilesort SPU. At
> this stage, it has nothing to do with DMX.
> 
> What should be rendered must be the same as that of the original
> simplemural.conf, but it is not.
> SAME part of the application window is rendered on both of the crserver
> windows, i.e. the left half.
> 
> Configuration for readback is the simplest, as will be shown below.
> Mike Houston's guess is that there may be a bug in arguments for DrawPixels.
> Even worse is that when the 'extract_depth' option is turned on, nothing is
> drawn at all.
> 
> Below is my modified simplemural.conf script. Only a few lines related with
> readbackSPU are added and without these, everything works fine.
> 
> Thanks in advance for any comment.

I found the problem.  On the server side, the initial current raster 
position needs to be translated by the origin of the server's tile. 
Normally, the first call to glRasterPos/glWindowPos would set it 
correctly, but the tilesort SPU's state tracker was filtering out that 
state change.

Try applying this patch to crserverlib/server_context.c

-Brian