You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(15) |
Oct
|
Nov
(1) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
|
Feb
(2) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2004 |
Jan
|
Feb
(9) |
Mar
(1) |
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(1) |
2010 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Brian P. <bri...@tu...> - 2004-05-18 14:54:48
|
ozg...@su... wrote: > Hi, > > I could not get the psubmit_last demo working, the crappfaker gives the > following error... > > CR Error(s64:2172): "/usr/share/cr-1.7/bin/Linux/psubmit" terminated > with uncaught signal=11 (SIGSEGV) > > I can run the psubmit_first without errors, yet psubmit_last does not > work in both RedHat 8.0 and Mandrake 9.1 with Chromium 1.7. It seems > sort last is not working on my system, yet I need to develop a sort last > rendering algorithm, hence the problem. If you study the psubmist_last.conf file you can find the exact command line arguments used to run psubmit. Then, instead of running crappfaker, run 'gdb psubmit <arguments>'. When it crashes you'll be able to get a stack trace. But first, recompile Chromium with RELEASE=0 (see options.mk). And, in lib/Linux/ make these symlinks: ln -s libcrfaker.so libGL.so ln -s libcrfaker.so libGL.so.1 You don't say which graphics card or driver you're using. In the past, there have been problems with NVIDIA's driver related to psubmit (sort-last rendering). -Brian |
From: <ozg...@su...> - 2004-05-18 14:27:44
|
Hi,<br> <br> I could not get the psubmit_last demo working, the crappfaker gives the following error...<br> <br> CR Error(s64:2172): "/usr/share/cr-1.7/bin/Linux/psubmit" terminated with uncaught signal=11 (SIGSEGV)<br> <br> I can run the psubmit_first without errors, yet psubmit_last does not work in both RedHat 8.0 and Mandrake 9.1 with Chromium 1.7. It seems sort last is not working on my system, yet I need to develop a sort last rendering algorithm, hence the problem.<br> <br> Thanks in advance...<br> Ozgur <br> <p> <br> </p> |
From: Esposito, C. <chr...@bo...> - 2004-03-02 23:30:10
|
Hi all, I just downloaded 1.6 onto a Linux box (RH9, kernel 2.4.20.8, ATI fireGL 7800 video w/ATI driver). I didn't notice any errors in the Chromium build, and the mothership, crserver, and crappfaker all started without any errors (all 3 running on localhost, with the CR_MOTHERSHIP env variable unset). The fonttest window appeared, but had no text in it. I then killed the 3 apps, and noticed an error message from crserver as it was dying that the total output area was 0x0. I don't know if this message was an artifact of the app being killed, or associated with the lack of rendered output. Any suggestions as to what went wrong? Thanks, Chris |
From: Robert E. <pa...@tu...> - 2004-02-20 15:47:59
|
From Joel: > So here is a way to nicen the syntax. > > -Every Node type gets a list of constraint attributes. This is implicit in > the "#" dynamic marker syntax as well, I believe. > > -The constructor definitions get changed to be of the form: > > CRNetworkNode( object, tagString="match_string" ) > > and the treatment of object depends on tagString. The default behavior adds a > match-this-string-type constraint to the node's constraint list, so that old > scripts don't break and old tools and conf writers don't get confused. The > availability of tagString and a new Node.addConstraint() method allows for a > lot of future expansion. One could even do something like: > > CRNetworkNode( "foo", "dynamic_host" ) > > to get exactly the internal logic your proposal would give with > > CRNetworkNode( "#foo" ) I've refined this a bit during implementation. - Every node constructor is of the form: CR.*Node(host, constraint = "name", constraintArg = None) - The "host" argument represents the machine. By default, it must be the name of the connecting machine; but with dynamic hosts, this isn't necessarily the case. With dynamic hosts, it's just a string identifier that can be used to differentiate hosts. - The "constraint" and "constraintArg" allow control over which hostnames will match to which nodes. By default, the "name" constraint only matches incoming connecting hostnames to nodes with identical hostnames provided. Other variants include: node = CRNetworkNode("server1", "dynamic") (the "dynamic" test allows the test to match any incoming connecting hostname to this node) node = CRNetworkNode("server1", "regex", "name[0-9]*") (the "regex" test only allows incoming connecting hostnames that match the given regular expression to match the node) pattern = re.compile("name[0-9]*") node = CRNetworkNode("server1", "pattern", pattern) (the "pattern" test works like the "regex" test, but with a precompiled pattern) node = CRNetworkNode("server1", "regex_full", ".*\.psc\.edu") (the "regex_full" test checks the regular expression against the fully qualified domain name of an incoming connecting machine) pattern_full = re.compile(".*\.psc\.edu") node = CRNetworkNode("server1", "pattern_full", pattern_full) (the "pattern_full" test works like the "regex_full" test, but with a precompiled pattern) - A single node may have multiple constraints added to it, via the new node.AddConstraint(constraint, constraintArg) method. A node will only be accepted for an incoming connection name if all constraints are satisfied. - If all the constraints for a node are static (i.e., allow the name of the connecting host to be known before incoming connections are made), the node is static. If any of the constraints is dynamic (i.e., have to be resolved to true hostnames before use), the node is dynamic. For any dynamic node, the "host" parameter is a placeholder; it is a variable name, not a machine name. I use special syntax to make it clear that the supplied host name is a dynamic variable rather than an explicit host name, such as: node = CRNetworkNode("#server1", "dynamic") or node = CRNetworkNode("SERVER1", "dynamic") but such syntax is not required. - When an incoming connection is made, all possible static matches are tried, then all already-resolved dynamic matches are tried, before any new dynamic matches are resolved. When dynamic matches are resolved, the first node of the appropriate type (i.e. a CRNetworkNode for a server, a CRApplicationNode for an app faker, etc.) that satisfies all the constraints will be used. Multiple processes running on the same host can resolve multiple dynamic nodes (all to the same hostname, of course). - To define a bank of network nodes that will be resolved to incoming server connections, use something like: for serverNumber in range(NUM_SERVERS): node = CRNetworkNode("server%d" % serverNumber) ... # configure the node and add it I believe this satisfies all the requirements we've had to date. For futures, it's easy to add more constraint tests, if more are needed; I think a special "or" test would be great, so that you can design configuration files that work without change in very different environments... but I'm not planning on making these changes at this time. Bob Ellison Tungsten Graphics, Inc. |
From: Robert E. <pa...@tu...> - 2004-02-19 18:12:06
|
> Recalling the observed problem, in very large-scale environments, it can > take appreciably long for each server involved to contact the mothership > and get its configuration. > > A "daughtership" (perhaps a better analogy would be a "surrogate > mothership") relieves some of the pressure by providing an additional > "contact point". The daughtership contacts the mothership to collect > the entire configuration; from that point, servers may contact the > daughtership instead of the mothership to get their own configuration > details. The daughtership can tell the servers how to configure and > what to do just as well as the mothership can. ... > What doesn't work: > > - Autostart. There are no node types (yet?) for daughterships, so they > cannot be autostarted. > > - Dynamic hosts. A daughtership cannot resolve a dynamic host itself; > it must contact its mother (otherwise, multiple daughterships may all > resolve the same dynamic host to different actual hostnames, which will > cause them to not be equivalent any more). I've got code ready for check in (after just a few more tests) that supports dynamic hosts and daughterships. In the process of working with this and testing it, I've noted a few more things about daughterships I wanted to share. - No "cousins" are supported. Daughterships cannot broker communication requests between each other. That is, if a server and a client are supposed to ultimately communicate with each other, they must both connect to the same mothership or daughtership. Otherwise, one daughtership can sit on a "connectrequest" waiting for the matching "acceptrequest", while the other daughtership has the "acceptrequest" and is waiting for the "connectrequest". Although we could have the daughterships exchange information when they get these requests, such would complicate and delay communication between the nodes; you'd do just as well or better to have a single mothership. - Although dynamic hosts do work with daughterships now, I would hesitate to recommend their use together, as they tend to eliminate the scalable performance advantage daughterships can provide. (At least I believe they will; without a large cluster at my disposal, it's difficult to be certain.) When a configuration uses dynamic hosts (that is, unspecified host names that are resolved when appropriate servers contact the mothership), two things must happen: the mothership must track and uniquely resolve these dynamic names when necessary; and the mothership must suspend the application until all the dynamic hosts are resolved. (One of the first things that stub OpenGL library will do upon contact is get a list of all servers; all the dynamic servers must be resolved before this can happen.) Both of these are managed by having the "grandmothership" (i.e., a single mothership that has no parent itself, only daughters) handle all the resolution. So whenever a daughtership needs to resolve a dynamic host, it suspends the request that caused the resolution, and asks its mother to resolve the dynamic host on its behalf. Whenever the grandmothership resolves a dynamic host (either to handle a dynamic host contacting it directly, or to handle a request from a daughter), it tells all its daughters that a match has been made, so they can all log the match and use it. When a daughtership receives a match communication, it looks to see if it has any suspended connections waiting for this match; and if it does, it resumes them. This all works very well to keep daughterships and motherships synchronized, but does introduce a round-trip to the mothership (or perhaps more than one, if there are multiple layers of matriarchal hierarchy) to resolve any dynamic host. And this will likely be slower than direct connections to the mothership (although again I cannot be certain, without a large cluster to test with). I'll be making changes to the documentation to describe this, and then I'll be done with what I had planned to do along these lines. Bob Ellison Tungsten Graphics, Inc. |
From: Robert E. <pa...@tu...> - 2004-02-14 23:32:03
|
> So here is a way to nicen the syntax. > > -Every Node type gets a list of constraint attributes. This is implicit in > the "#" dynamic marker syntax as well, I believe. > > -The constructor definitions get changed to be of the form: > > CRNetworkNode( object, tagString="match_string" ) > > and the treatment of object depends on tagString. The default behavior adds a > match-this-string-type constraint to the node's constraint list, so that old > scripts don't break and old tools and conf writers don't get confused. The > availability of tagString and a new Node.addConstraint() method allows for a > lot of future expansion. One could even do something like: > > CRNetworkNode( "foo", "dynamic_host" ) > > to get exactly the internal logic your proposal would give with > > CRNetworkNode( "#foo" ) I'm fine with this. I'll give others a day to review and comment, and if no one objects, I'll change it on Tuesday. Bob Ellison Tungsten Graphics, Inc. |
From: Robert E. <pa...@tu...> - 2004-02-14 23:30:19
|
>> % export CRMOTHER=host:port # where is my mother? >> % export CRMOTHERSHIP=host:port # what "mothership" should I look like? >> % python .../cr/mothership/server/daughtership.py > > > I'm not clear on the purpose of adding the CRMOTHER environment variable. In > the daughtership's environment CRMOTHERSHIP should presumably be the > daughter's mother. The only remaining question is what port number the > daughership should open for incoming requests. In the current implementation, > I think the mothership picks the port based on the parameter to CR.Go(), > doesn't it? The "interesting" syntax is provided to match the current use of CRMOTHERSHIP, which is not only used by the servers, but also by the mothership herself (to configure her listening port). The daughtership will contact a mothership, read a configuration, and then execute just as a mothership would - including reading the CRMOTHERSHIP variable in order to determine which port to set herself up on. Clearly, we can't have both mothership and daughtership setting themselves up on the same port; so either we add a variable to configure the "extra" values that the daughtership needs that the mothership does not (i.e., the address of the mothership to contact), or the daughtership changes the value of CRMOTHERSHIP in the environment before executing. Three options: - Maintain the utility of CRMOTHERSHIP for configuring daughterships, and add a new variable for identifying the true mothership (current implementation) - Maintain the utility of CRMOTHERSHIP for identifying a mothership to contact, and add a new variable for configuring the daughtership - Deprecate the use of CRMOTHERSHIP for configuring daughterships (all other current utility remains); use CRMOTHERSHIP to identify the parent, and otherwise require the daughtership to be fully configured (perhaps via command line options). I'm open for any. > Here is another question to consider: how does a node pick which mothership to > talk to? Is there any interest in being able to say something like: > > setenv CRMOTHERSHIP "node1:1234,node2:5678,node3:1324" > > to specify that the Node has a variety of choices? I could live without it, > but some piece of software somewhere has to get smart enough to choose. That > could be the Node code itself, or it could be whatever I write that spawns the > Node process. The clients would have to define a policy for which mothership is preferred, which in some cases would be pretty clear, but in other cases rather murky. I'd rather leave this to config files. Bob Ellison Tungsten Graphics, Inc. |
From: Robert E. <pa...@tu...> - 2004-02-10 07:09:30
|
> OK, I had failed to understand that. It certainly sounds useful, but it > doesn't really match anything *I* expect to need. I would expect to have more > of a situation where I ask for 1000 CRApplicationNodes and 64 CRNetworkNodes > and don't care what their hostnames are (subject to some constraints; see > below). I could generate 1064 unique strings starting with '#', but it seems > pretty awkward. I'm wondering if there is a way to specify my setup without > the extra strings. You'd have to generate the unique nodes, anyway, right? I'd imagine a config file something like: for appNodeNumber in range(NUM_APPNODES): appNode = CRApplicationNode("#appnode%d" % appNodeNumber) cr.AddNode(appNode) Shouldn't be any more complex than any other way to set up a large number of similar nodes (and still a heckuva lot easier than providing the individual names of each node). > It begins to seem like the original specification was wrong, and > CRNetworkNode() shouldn't take a string at all. Rather, one might have done > something like: > > import re > anyPSCHost= re.compile('.*\.psc\.edu') > node1= CRNetworkNode() > node2= CRNetworkNode() > node3= CRNetworkNode() > node4= CRNetworkNode() > > node2.addConstraint('match_string', 'somenode.psc.edu' ) > node3.addConstraint('match_regex', anyPSCHost) > node4.addConstraint('same_host_as',node1) > > node1 could be assigned to any hostname, node2 would match only > somenode.psc.edu, node3 would require a hostname matching the AnyPSCHost > regex, and node4 would match only the host assigned to node1. I believe the > 'isinstance' problem is avoided here because the initial string essentially > specifies the type of the second argument. Oh, note that I haven't said > 'node2.Conf(...)' because it doesn't really configure the *node*; it only > configures the host matching logic within the mothership. It does some yucky things if, using the example above, node4 happens to contact the mothership before node1 does. We'd need to parse trees of constraints (in general) to resolve "same_host_as", and we'd have to be able to handle circular references... It also becomes more difficult to specify and handle some relatively simple cases; and can produce interesting results if someone unwittingly comments out or deletes a constraint line (when all of a sudden the network node begins acting like it's constrained to "localhost" instead of being dynamic). The above *is* a clever generalization that's functionally equivalent to my original and avoids the new "#" syntactic element; but it seems to me to be difficult to fit into the current paradigm (with all its backwards-compatible behavioral quirks) cleanly, without introducing more confusion and/or need for wizards and gurus to create config files... Bob |
From: Robert E. <pa...@tu...> - 2004-02-10 06:46:44
|
Hi, all - I've got some preliminary support checked in for "daughterships". It's incomplete (there are some tricky issues left), but it's there to provoke discussion. The changes shouldn't affect any other uses. Recalling the observed problem, in very large-scale environments, it can take appreciably long for each server involved to contact the mothership and get its configuration. A "daughtership" (perhaps a better analogy would be a "surrogate mothership") relieves some of the pressure by providing an additional "contact point". The daughtership contacts the mothership to collect the entire configuration; from that point, servers may contact the daughtership instead of the mothership to get their own configuration details. The daughtership can tell the servers how to configure and what to do just as well as the mothership can. Multiple daughterships are supported; a hierarchy of daughterships is also possible (as each daughtership, after getting details from its mother, is a fully capable mothership). To start a daughtership: % export CRMOTHER=host:port # where is my mother? % export CRMOTHERSHIP=host:port # what "mothership" should I look like? % python .../cr/mothership/server/daughtership.py After that, any other server may be run with CRMOTHERSHIP pointing at the daughtership or at the original mothership, equivalently. What doesn't work: - Autostart. There are no node types (yet?) for daughterships, so they cannot be autostarted. - Dynamic hosts. A daughtership cannot resolve a dynamic host itself; it must contact its mother (otherwise, multiple daughterships may all resolve the same dynamic host to different actual hostnames, which will cause them to not be equivalent any more). But a daughtership in the middle of a connection request (which can trigger dynamic host matching) can't easily ask the mothership for information; it can send the request easily enough, but it can't guarantee that the next information coming from its mother is the correct response (because the mother propagates some commands to its daughterships). The logic to handle this gets spotty after that; you end up having to suspend the connection request and return to the communications loop, waiting until the proper data comes in; further, we lose the advantage of having a daughtership if there are many dynamic hosts... Providing nodes for daughterships and enforcing a strict hierarchy (i.e. servers may only contact their designated daughterships) would solve both problems, but limit flexibility, introduce complexity (especially with the graphical config tool), and possibly introduce confusion (if a dynamically-hosted crserver points to the wrong mothership by accident, it could still resolve, but ultimately leave one daughtership not knowing what to do with an extra connection, and another one waiting for a missing connection). I think it would be easier to code for the former (the daughtership contacts the mothership for dynamic host matching) than for the latter (nodes & hierarchy). But the whole thing may be complex enough to not be worth the effort; perhaps these changes should be abandoned, and another mechanism for large clusters considered... Thoughts? Bob Ellison Tungsten Graphics, Inc. |
From: Karl R. <rk...@vr...> - 2004-02-05 17:06:42
|
> Regarding the problem of starting huge numbers of nodes (current code requires > all nodes to contact the mothership for configuration, and the mothership is a > single process that handles the connections linearly)... I've probably joined in the middle of some thread, so ignore me if necessary... What about caching config info on the server side? At least here I run the same config over and over again, switching between apps as people change their mind as to what they want to see.. This won't help any when you change nodes in a config or whatnot, but, maybe thats a different problem.. |
From: Robert E. <pa...@tu...> - 2004-02-04 18:43:45
|
Regarding the problem of starting huge numbers of nodes (current code requires all nodes to contact the mothership for configuration, and the mothership is a single process that handles the connections linearly)... "Daughterships" have been suggested as one option for solving this problem; I'm ruminating on the concept. A daughtership is a process that receives information from a mothership, and then acts on behalf of the mothership, brokering connections and passing configuration information off to connecting processes. Servers should be able to connect to the mothership or any daughtership transparently, with equal functionality (in fact, a server should not itself be able to determine any difference between the mothership and a daughtership). Further, not only should multiple daughterships be possible, but a hierarchy of daughterships should be possible; this would theoretically allow n log n responsiveness. (However, I think there must be a top-level mothership, a "grandmothership", to which the application connects, which manages sending the application the signal to continue; in this case symmetry of motherships and daughterships is broken.) A daughtership will ask its mothership for the node graph when it starts up; but a two-way connection is necessary to maintain state in the distributed system (e.g. to propagate "setparam" or "reset" commands to the whole system, or to manage dynamic host markers [mentioned in another thread]). A daughtership that receives one of these on any connection but the upstream connection must propagate it to its mothership; a mothership that receives one of these must propagate it to all its downstream daughterships (except for the one that originated the command, if any, although this wouldn't likely make a difference). If there are dynamic markers in the system (again, see the other thread), a daughtership must convey connections to its mother, so that the "grandmothership" can track all the dynamic markers, resolve their names, and determine when to allow the application to continue. (Motherships will also need a new instruction just for their daughters, to tell them to update their own dynamic marker tables, so they can resolve requests as well, and so they know when all dynamic markers have been resolved so that they don't need to propagate connections upward...) -------------------------------------------------------------------------- I've thought about having "ungraphed" daughterships, "graphed" daughterships, and "noded" daughterships, as three different approaches. - Ungraphed daughterships: Daughterships are independent processes, with no associated node. In this case, it's up to the user to start daughterships (as many or as few) as are desired, and to set up their hierarchy (via each one's understanding of where its mothership is). Chromium has no knowledge of whether daughterships are present, or how many. Any network server can be told to connect to any mothership or daughtership equivalently. Chromium need not know anything else. - Graphed daughterships: Daughterships are full-fledged Chromium nodes, with a new node type created for them. Servers are associated with particular daughterships, and Chromium is aware of which server is associated with which daughtership. Chromium can auto-start daughterships (like any other node). Chromium also waits for connections from daughterships; a daughtership signals its mother when all its connections have been made (these can either be simple server connections, or daughterships signalling that their connections are all complete). An advantage is that daughterships "know" which nodes are theirs, and which are dynamic; there's no need to propagate connection information, since daughterships can resolve dynamic markers themselves. It may also be an advantage that the entire configuration need not be communicated to each daughtership - the mothership knows how much of the configuration each daughtership requires, so it isn't necessary to send the whole huge configuration to every daughtership. However, the disadvantage is the extra complexity of managing this hierarchical data. - Noded daughterships: Daughterships can have nodes (but these aren't required); nodes are only provided for autostart capabilities. This hybrid solution provides one primary advantage of the graphed daughtership case (i.e. the ability to autostart daughterships), without all the complexity of managing a full hierarchy in Chromium (although the daugherships can still be set up in a hierarchy, Chromium wouldn't be intrinsically aware of this). -------------------------------------------------------------------------- Thoughts? Other ideas? Bob Ellison Tungsten Graphics, Inc. |
From: Robert E. <pa...@tu...> - 2004-02-04 17:56:13
|
> Another feature that would be really nice would be some sort of wildcarding > for expected host names. If I'm running Chromium between PSC machines and > Argonne vis cluster machines (with names like tg-v???.uc.teragrid.org) it > would be nice to be able to say 'Expect to hear from 32 machines with names of > that form'. As it stands now, I have to start up an interactive job at > Argonne, see what nodes I get assigned, and copy those node names into a .conf > file. Towards this end... The current mothership.py (checked in yesterday) has a first stab at something like this. It offers a config file the option of specifying a dynamic marker instead of a host name for calls like CRNetworkNode(). Syntactically, instead of specifying a host name, you specify a string starting with the pound "#" character (e.g., "#1", "#2", "#server12", etc. The mothership collects all the dynamic markers. After it starts listening for connections, but before it signals the main application to continue, the mothership will listen for connections from the servers, and will resolve markers to appropriate hostnames. (This has to be done before the main application continues, because one of the first thing the main application will do is ask for the list of servers, which must all be resolved by that point.) Constraints: - The main application cannot continue until all the dynamic servers have connected. This could reduce startup performance somewhat. - Windows Python doesn't implement signalling, so there's a race condition on that platform (as the mothership doesn't have the ability to signal the main application to continue). If the mothership and main application are running on Windows, the mothership and servers will have to be started sufficiently before the application to allow all the servers to connect (or the application will have to sleep for an undefined amount of time). - The mothership cannot be dynamic; the machine hosting the mothership must be known to all the servers (so that they can connect). - Servers cannot be autostarted via this mechanism; if the mothership is going to start the server, it clearly must know the server's name. It can't wait until the server makes contact to resolve the name (at least until we develop clairvoyant software ;-) Is this useful at all? Are there other things that can be done to make it better? (I didn't implement a syntax for matching the host name against an expected pattern, because I didn't think it necessary (would a random unexpected machine really start a crserver and make contact with an unknown mothership?), but it is still possible to implement, if it's needed.) Bob Ellison Tungsten Graphics, Inc. |
From: Brian P. <br...@tu...> - 2003-03-26 14:42:49
|
Dan Hiepler wrote: > I would like to use Vrjuggler DR3 with Chromium 1.1 on Linux Redhat 8. > > I beleive the recommended way is to use a separate viewports for each wall > in VrJuggler. For the simulator the file > vrjuggler/data/configFiles/sim.c6viewports.mixin.config > is recommmended. > > Chromium does not seem to work with the viewports appearing on screen as > an unfolded cube. In the case of a single tile Chromium appears to require it > to start at [0,0]. Do I have to arrange the VrJuggler viewports into a > rectangle such as 1 row 6 coloumns ? > > I would like to get a 4 wall passive stereo environment working. > This will use separate left and right stereo channel computers and > projectors for each wall. 8 computers altogether and 8 projectors. > > Since the chromium tilesort spu maps by screen area how do I configure > VrJuggler and Chromium to send each walls left and right projection data > to separate computers ? > Do I have to use a different screen area by altering my glViewport for > left and right channels ? > > Are there any special synchronization issues for this 8 computer > 4 wall passive stereo environment ? > > Cluster juggler is another approach but I do not want to replicate my large > amount of input data. The tilesort SPU requires that the tiles all be coplanar. It sounds like you've got a CAVE-like system. There's a facility for warped tiles (see the docs) but I believe that applies only to warping within the image plane. You're not the first person to ask about this and I've suggested extending the tilesort SPU to work with non-planer tilings but I don't think anyone's tackled it. I hope I haven't misunderstood what you're doing. -Brian |
From: Dan H. <dh...@il...> - 2003-03-26 00:51:04
|
I would like to use Vrjuggler DR3 with Chromium 1.1 on Linux Redhat 8. I beleive the recommended way is to use a separate viewports for each wall in VrJuggler. For the simulator the file vrjuggler/data/configFiles/sim.c6viewports.mixin.config is recommmended. Chromium does not seem to work with the viewports appearing on screen as an unfolded cube. In the case of a single tile Chromium appears to require it to start at [0,0]. Do I have to arrange the VrJuggler viewports into a rectangle such as 1 row 6 coloumns ? I would like to get a 4 wall passive stereo environment working. This will use separate left and right stereo channel computers and projectors for each wall. 8 computers altogether and 8 projectors. Since the chromium tilesort spu maps by screen area how do I configure VrJuggler and Chromium to send each walls left and right projection data to separate computers ? Do I have to use a different screen area by altering my glViewport for left and right channels ? Are there any special synchronization issues for this 8 computer 4 wall passive stereo environment ? Cluster juggler is another approach but I do not want to replicate my large amount of input data. Dan Hiepler dh...@il... |
From: Alan H. <al...@tu...> - 2003-02-11 08:41:06
|
On Mon, Feb 10, 2003 at 10:12:30 -0500, Chen, Zhe wrote: > Hi, > > I installed Cygwin on my computer and tried to compile CR-1.1 in the > Cygwin shell, but when I type 'make' under tha folder, it gives something > like this: > > ------------------------------------------------------------------- > Just parsing the OpenGL header file! > -------------------------------------------------------------------- > here we go... > make[1]:***[gl-header.parsed] Error 255 > make:***[glapi_parser.subdir] Error 2 > > I don't know what's wrong... could any body tell me what's going on in here? > Thanks a lot! You need Microsoft Visual C to compile Chromium. The Cygwin environment is not enough. You should really be posting questions like this to chromium-users. Alan. |
From: Chen, Z. <Zc...@te...> - 2003-02-11 03:12:33
|
Hi, I installed Cygwin on my computer and tried to compile CR-1.1 in the Cygwin shell, but when I type 'make' under tha folder, it gives something like this: ------------------------------------------------------------------- Just parsing the OpenGL header file! -------------------------------------------------------------------- here we go... make[1]:***[gl-header.parsed] Error 255 make:***[glapi_parser.subdir] Error 2 I don't know what's wrong... could any body tell me what's going on in here? Thanks a lot! Best regards, Zhe |
From: Ravid <ra...@te...> - 2002-11-07 15:05:43
|
Hello, My name is Ravid and I've been "playing" with the Chromium system for some time. In the last few days I tried the release version (1.0) and followed the conversation about the auto start up. In your explanations you instruct to create a configuration file which the crfaker will use to configure the environment. But when using the Auto start method the render in the server side run it's defaults and not the configuration file ones, It's because no Mothership is answering it. If you have any correction of what I just describe or any suggestion please reply. Thanks a lot Ravid. |
From: Alan H. <al...@tu...> - 2002-09-20 22:42:34
|
On Fri, Sep 20, 2002 at 04:20:54PM -0600, Brian Paul wrote: > > I've checked in all my work related to auto-starting chromium. > > At this point, I can run programs like city, atlantis by just > typing their name and have chromium fire up everything automatically. > Only tested on Linux for now. I'm following up on the Windows bits & pieces now. Alan. |
From: Brian P. <br...@tu...> - 2002-09-20 22:20:02
|
I've checked in all my work related to auto-starting chromium. At this point, I can run programs like city, atlantis by just typing their name and have chromium fire up everything automatically. Only tested on Linux for now. I've documented the process in cr/doc/autostart.html (which is hooked into the docs index). More to do, but read the docs and let me know what you think. -Brian |
From: Sean A. <sea...@ll...> - 2002-09-20 04:16:10
|
Brian Paul wrote: > But I have nagging suspicion that using a %p-style subtitution might give > us some future-proofing, just in case. I'll see... Yeah, I do like the idea in general. I just don't know quite what should go there yet... -Sean __ sea...@ll... |
From: Brian P. <br...@tu...> - 2002-09-20 01:16:18
|
Sean Ahern wrote: > Brian Paul wrote: > >>% setenv CR_CONFIG "mywall.conf -layout 3x2 %p" >>% city >> >>Where %p would get replaced by "city + arguments", but I think just >>appending the program to the end of the CR_CONFIG string might be >>sufficient. > > > I think you're right. Plus, do you even have access to city's argument > list? I don't. But I have nagging suspicion that using a %p-style subtitution might give us some future-proofing, just in case. I'll see... -Brian |
From: Sean A. <sea...@ll...> - 2002-09-19 23:41:38
|
Brian Paul wrote: > % setenv CR_CONFIG "mywall.conf -layout 3x2 %p" > % city > > Where %p would get replaced by "city + arguments", but I think just > appending the program to the end of the CR_CONFIG string might be > sufficient. I think you're right. Plus, do you even have access to city's argument list? -Sean __ sea...@ll... |
From: Brian P. <br...@tu...> - 2002-09-19 23:12:37
|
Yup, I was planning on that. I could get a bit fancier: % setenv CR_CONFIG "mywall.conf -layout 3x2 %p" % city Where %p would get replaced by "city + arguments", but I think just appending the program to the end of the CR_CONFIG string might be sufficient. -Brian Sean Ahern wrote: > This sounds wonderful! > > I wonder if we could expand CR_CONFIG to pass arguments to the scripts (as > you seem to be building support for). That way, you could do this: > > % setenv CR_CONFIG "mywall.conf -layout 3x2" > % city > > And have the tilesorter Do The Right Thing (TM). > > -Sean > > Brian Paul wrote: > >>I've spent the afternoon prototyping something new. The faker >>library now does the following: >> >>1. If the faker lib is able to contact the mothership, proceed normally. >> Otherwise... >> >>2. Look if the CR_CONFIG env var is set. If so, it names a desired >> config file (ex: crdemo.conf) >> >>3. Otherwise, find the name of the running process (ex: city) >> Look in ~/.crconfigs for a config for city (ex: crdemo.conf) >> >>4. Spawn a mothership process (ex: exec("python crdemo.conf city")) >> >>5. The crdemo.conf file can auto-start a crserver. >> >>6. An atexit() handler kills the mothership when the app exits. >> >> >>So, I can run city with Chromium just by typing "city <return>". >>I have symlinks from libGL.so to libcrfaker.so. >> >>How does that sound for a first cut? >> >>-Brian > > __ > sea...@ll... > > |
From: Sean A. <sea...@ll...> - 2002-09-19 23:09:21
|
This sounds wonderful! I wonder if we could expand CR_CONFIG to pass arguments to the scripts (as you seem to be building support for). That way, you could do this: % setenv CR_CONFIG "mywall.conf -layout 3x2" % city And have the tilesorter Do The Right Thing (TM). -Sean Brian Paul wrote: > I've spent the afternoon prototyping something new. The faker > library now does the following: > > 1. If the faker lib is able to contact the mothership, proceed normally. > Otherwise... > > 2. Look if the CR_CONFIG env var is set. If so, it names a desired > config file (ex: crdemo.conf) > > 3. Otherwise, find the name of the running process (ex: city) > Look in ~/.crconfigs for a config for city (ex: crdemo.conf) > > 4. Spawn a mothership process (ex: exec("python crdemo.conf city")) > > 5. The crdemo.conf file can auto-start a crserver. > > 6. An atexit() handler kills the mothership when the app exits. > > > So, I can run city with Chromium just by typing "city <return>". > I have symlinks from libGL.so to libcrfaker.so. > > How does that sound for a first cut? > > -Brian __ sea...@ll... |
From: Brian P. <br...@tu...> - 2002-09-19 22:42:51
|
Brian Paul wrote: > > I've spent the afternoon prototyping something new. The faker > library now does the following: > > 1. If the faker lib is able to contact the mothership, proceed normally. > Otherwise... > > 2. Look if the CR_CONFIG env var is set. If so, it names a desired > config file (ex: crdemo.conf) > > 3. Otherwise, find the name of the running process (ex: city) > Look in ~/.crconfigs for a config for city (ex: crdemo.conf) > > 4. Spawn a mothership process (ex: exec("python crdemo.conf city")) > > 5. The crdemo.conf file can auto-start a crserver. > > 6. An atexit() handler kills the mothership when the app exits. > > > So, I can run city with Chromium just by typing "city <return>". > I have symlinks from libGL.so to libcrfaker.so. > > How does that sound for a first cut? The next thing I've done now is to enhance the config files written by the graphical configuration tool so that they'll accept command line parameters at run time. For example: 1. Use the graphical config tool to design a sort-first config. Let's call it "tile.conf". 2. Running "python tile.conf --help" prints the options: Usage: tile.conf [--help] [-c columns] [-r rows] [-w tileWidth] [-h tileHeight] [-s servers] [program] 3. Run the config, specifying the mural size and servers: python tile.conf -c3 -r2 -s cr1,cr2,cr3,cr4,cr5,cr6 atlantis This will setup a 3x2 mural running on the named servers. So hopefully, someone can whip up a basic sort-first, sort-last or image reassembly configuration with the configuration tool, then be able to fine-tune the parameters at runtime. The next step will be to demonstrate/test this using the auto-start system I got going yesterday... -Brian |