Menu
▾
▴
chromium-users — Mailing list for all users of the Chromuim rendering system
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(10) |
Jul
(5) |
Aug
(20) |
Sep
(12) |
Oct
(1) |
Nov
(5) |
Dec
(5) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(4) |
Feb
(13) |
Mar
(14) |
Apr
(33) |
May
(15) |
Jun
(49) |
Jul
(24) |
Aug
(90) |
Sep
(13) |
Oct
(85) |
Nov
(25) |
Dec
(6) |
| 2003 |
Jan
(9) |
Feb
(89) |
Mar
(85) |
Apr
(98) |
May
(30) |
Jun
(55) |
Jul
(79) |
Aug
(78) |
Sep
(77) |
Oct
(47) |
Nov
(48) |
Dec
(18) |
| 2004 |
Jan
(75) |
Feb
(176) |
Mar
(137) |
Apr
(67) |
May
(119) |
Jun
(128) |
Jul
(53) |
Aug
(50) |
Sep
(46) |
Oct
(55) |
Nov
(53) |
Dec
(25) |
| 2005 |
Jan
(34) |
Feb
(21) |
Mar
(29) |
Apr
(48) |
May
(23) |
Jun
(35) |
Jul
(18) |
Aug
(69) |
Sep
(49) |
Oct
(35) |
Nov
(16) |
Dec
(7) |
| 2006 |
Jan
(21) |
Feb
(17) |
Mar
(16) |
Apr
(20) |
May
(48) |
Jun
(19) |
Jul
(23) |
Aug
(55) |
Sep
(42) |
Oct
(7) |
Nov
(7) |
Dec
(4) |
| 2007 |
Jan
(6) |
Feb
(17) |
Mar
(3) |
Apr
(6) |
May
(4) |
Jun
(12) |
Jul
(1) |
Aug
(7) |
Sep
(11) |
Oct
(1) |
Nov
(10) |
Dec
(4) |
| 2008 |
Jan
(5) |
Feb
(7) |
Mar
(12) |
Apr
(21) |
May
(1) |
Jun
(3) |
Jul
|
Aug
(1) |
Sep
(2) |
Oct
(4) |
Nov
(7) |
Dec
(9) |
| 2009 |
Jan
(4) |
Feb
|
Mar
|
Apr
(5) |
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
(10) |
Oct
(1) |
Nov
|
Dec
(2) |
| 2010 |
Jan
(4) |
Feb
|
Mar
(3) |
Apr
|
May
(1) |
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2013 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: Ade F. <ad...@te...> - 2006-12-08 17:11:10
|
I'm just trying to get Chromium (1.9) working with our new graphics cluster, and I have things working nicely over the first network interface of each machine (gigabit ethernet). However, we also have an Infiniband setup as the second network infrastructure and I am struggling to get this going. I have tried both the IB and SDP layers. Got a really strange error with IB and noted the recommendation on this list from Mike Houston that the SDP layer is better for use. However, with that I am having the problem of getting the hostname and IP addresses to match. The Chromium Docs suggest that setting CR_SDP_SUFFIX is necessary to represent that fact that our Infiniband interfaces are named 'hostname-ib', but this doesn't seem to be working. I am getting the Mothership not heard of 'hostname', expected 'hostname-ib' (as specified in the config file). I have tried with IP addresses, and with and without the '-ib' in both the config file and the CRMOTHERSHIP variable, but to no avail. Is there any particularly suggested practice here that might help me? Really eager to get this going, as after a year or so away from Cr, it's nice to be back playing with things, and this time on kit that can actually run it well! Thanks Ade |
|
From: Daniel E. S. <dan...@gm...> - 2006-11-28 15:48:35
|
Hi all, I am trying to modify the GL stream that chromium is sending to the render nodes to only modify the ModelView Matrix. I override all the usual suspects and don't allow calls to things like glViewport, glOrtho, glMultMatrix(when not in ModelView), etc. However, even with making all of these calls as no-ops(which I verified with logging) the Projection Matrix on the render nodes is still being affected. I also looked at crserverlib code and found it may have been setting up viewports in there too...but I don't really know enough about how chromium sets up remote viewport to intelligently mess with the code. So, my question is how does chromium set up the remote viewports and where do I need to intercept those calls to make sure that the Projection Matrix is not touched on render nodes. -Dan |
|
From: Daniel E. S. <dan...@gm...> - 2006-11-20 16:44:01
|
When updating the CVS version of Chromium from the 8/31/06 copy, crappfaker no longer starts up as expected and instead just starts rendering the GL application that was passed to it. However, when you preload the crfaker lib everything works as expected. See the output from the two different runs below: [dshipton@regatta ~]$ crappfaker CR Warning(regatta:11436): Couldn't find the CRMOTHERSHIP environment variable, defaulting to localhost CR Debug(regatta:11436): In crNetConnectToServer( "localhost", port=10000, mtu=8096, broker=0 ) CR Debug(regatta:11436): Connecting to regatta.infiscape.com on port 10000, with protocol tcpip CR Debug(regatta:11436): Done connecting to localhost (swapping=0) 3186.6 fps [dshipton@regatta ~]$ LD_PRELOAD=libcrfaker.so crappfaker CR Warning(regatta:11441): Couldn't find the CRMOTHERSHIP environment variable, defaulting to localhost CR Debug(regatta:11441): In crNetConnectToServer( "localhost", port=10000, mtu=8096, broker=0 ) CR Debug(regatta:11441): Connecting to regatta.infiscape.com on port 10000, with protocol tcpip CR Debug(regatta:11441): Done connecting to localhost (swapping=0) CR Debug(regatta:11442): In crNetConnectToServer( "localhost", port=10000, mtu=8096, broker=0 ) CR Debug(regatta:11442): Connecting to regatta.infiscape.com on port 10000, with protocol tcpip CR Debug(regatta:11442): Done connecting to localhost (swapping=0) CR Debug(regatta:11442): SPU 1/1: (1) "pack" CR Debug(regatta:11442): Initializing error SPU CR Debug(regatta:11442): Initializing pack SPU CR Warning(regatta:11442): Couldn't find the CRMOTHERSHIP environment variable, defaulting to localhost CR Debug(regatta:11442): In crNetConnectToServer( "localhost", port=10000, mtu=8096, broker=0 ) CR Debug(regatta:11442): Connecting to regatta.infiscape.com on port 10000, with protocol tcpip CR Debug(regatta:11442): Done connecting to localhost (swapping=0) CR Debug(regatta:11442): In crNetConnectToServer( "tcpip://regatta.infiscape.com:7000", port=7000, mtu=1048576, broker=1 ) CR Debug(regatta:11442): Connecting to regatta.infiscape.com on port 7000, with protocol tcpip CR Warning(regatta:11442): Couldn't find the CRMOTHERSHIP environment variable, defaulting to localhost CR Debug(regatta:11442): In crNetConnectToServer( "localhost", port=10000, mtu=8096, broker=0 ) CR Debug(regatta:11442): Connecting to regatta.infiscape.com on port 10000, with protocol tcpip CR Debug(regatta:11442): Done connecting to localhost (swapping=0) Any ideas? -Daniel |
|
From: Harviainen <tat...@tm...> - 2006-11-17 22:19:18
|
Hello all, First of all, I'd like to thank everyone who has been involved in the Chromium development. Chromium has been a great help for me as I have been working on a two wall Cave -like system. Recently I've been trying to run Wings 3D (a neat open source polygon modeling app) with Chromium but this has caused a problem that I haven't been able to solve. For some reason the SDL based window management of Wings causes Chromium to open multiple rendering windows on the server node. First, when Chromium is set up and application starts, multiple crserver rendering windows open in the server node and after that, a new window is opened every time the blank application window in the client node is resized. I'm running Chromium 1.9 debug build on two PCs, one running mothership and application with crfaker.dll and other running the crserver. I tried to inspect this issue and it seems that Wings is calling wglCreateContext several times when it starts, trying to initialize different opengl modes. Wings also sends wglCreateContext each time the application window is resized on client node. It looks like these wgl calls are changed into WindowCreate events by Chromium when they arrive to the server node. Can anyone explaing what is causing this or give some suggestions how I could prevent crserver from opening multiple windows? Any help would be greatly appreciated. Thanks! Tatu Harviainen |
|
From: Brian P. <bri...@tu...> - 2006-11-17 15:10:18
|
James Supancic wrote: > Texture Combine not supported? Why? > > I have an OpenGL program that isn't rendering properly, the print SPU > tells me that it is calling: > TexEnvi( GL_TEXTURE_ENV, GL_SOURCE0_RGB, GL_TEXTURE ) > TexEnvi( GL_TEXTURE_ENV, GL_OPERAND0_RGB, GL_SRC_COLOR ) > TexEnvi( GL_TEXTURE_ENV, GL_SOURCE1_RGB, GL_PRIMARY_COLOR ) > TexEnvi( GL_TEXTURE_ENV, GL_OPERAND1_RGB, GL_SRC_COLOR ) > TexEnvi( GL_TEXTURE_ENV, GL_COMBINE_RGB, GL_MODULATE ) > TexEnvi( GL_TEXTURE_ENV, GL_RGB_SCALE, GL_LINES ) > TexEnvi( GL_TEXTURE_ENV, GL_SOURCE0_ALPHA, GL_TEXTURE ) > TexEnvi( GL_TEXTURE_ENV, GL_OPERAND0_ALPHA, GL_SRC_ALPHA ) > TexEnvi( GL_TEXTURE_ENV, GL_SOURCE1_ALPHA, GL_PRIMARY_COLOR ) > TexEnvi( GL_TEXTURE_ENV, GL_OPERAND1_ALPHA, GL_SRC_ALPHA ) > TexEnvi( GL_TEXTURE_ENV, GL_COMBINE_ALPHA, GL_MODULATE ) > TexEnvi( GL_TEXTURE_ENV, GL_ALPHA_SCALE, GL_LINES ) > > I noticed that the Chromium documentation says > "Texture Combine test (Test number #85) not supported (not an error)." > > I noticed that the above shows that the program is setting the > GL_COMBINE_RGB and GL_COMBINE_ALPHA. > > Could the problem with my program be related to the lack of support > for Texture Combine? If yes, why isn't this supported? GL_ARB_texture_env_combine is supported. The results from the conformance tests haven't been updated in quite a while. -Brian |
|
From: James S. <arr...@gm...> - 2006-11-16 22:22:48
|
Texture Combine not supported? Why? I have an OpenGL program that isn't rendering properly, the print SPU tells me that it is calling: TexEnvi( GL_TEXTURE_ENV, GL_SOURCE0_RGB, GL_TEXTURE ) TexEnvi( GL_TEXTURE_ENV, GL_OPERAND0_RGB, GL_SRC_COLOR ) TexEnvi( GL_TEXTURE_ENV, GL_SOURCE1_RGB, GL_PRIMARY_COLOR ) TexEnvi( GL_TEXTURE_ENV, GL_OPERAND1_RGB, GL_SRC_COLOR ) TexEnvi( GL_TEXTURE_ENV, GL_COMBINE_RGB, GL_MODULATE ) TexEnvi( GL_TEXTURE_ENV, GL_RGB_SCALE, GL_LINES ) TexEnvi( GL_TEXTURE_ENV, GL_SOURCE0_ALPHA, GL_TEXTURE ) TexEnvi( GL_TEXTURE_ENV, GL_OPERAND0_ALPHA, GL_SRC_ALPHA ) TexEnvi( GL_TEXTURE_ENV, GL_SOURCE1_ALPHA, GL_PRIMARY_COLOR ) TexEnvi( GL_TEXTURE_ENV, GL_OPERAND1_ALPHA, GL_SRC_ALPHA ) TexEnvi( GL_TEXTURE_ENV, GL_COMBINE_ALPHA, GL_MODULATE ) TexEnvi( GL_TEXTURE_ENV, GL_ALPHA_SCALE, GL_LINES ) I noticed that the Chromium documentation says "Texture Combine test (Test number #85) not supported (not an error)." I noticed that the above shows that the program is setting the GL_COMBINE_RGB and GL_COMBINE_ALPHA. Could the problem with my program be related to the lack of support for Texture Combine? If yes, why isn't this supported? Thank you for your time, James Steven Supancic III |
|
From: <lia...@26...> - 2006-11-09 23:17:13
|
DQpoaSxhbGw6DQoNCkknbSAgc2V0dGluZyB1cCBhIG1pbmktY2x1c3RlciBvZiBmb3VyIG1h Y2hpbmVzIHRvIHRlc3QgQ3J1dCB3aXRoIHR3byBhcHBsaWNhdGlvbiBjbGllbnRzLih0aGUg YXBwbGljYXRpb24gY29kZSBpcyBwc3VibWl0IGluIHRoZSBwcm9ncyBvZiBjci0xLjgpLkZv bGxvd2luZyBpcyB0aGUgY29uZmlndXJlIGZpbGUuQnV0IHRoZSBzZXJ2ZXIgbm9kZSByZW5k ZXJpbmcgZG9lcyBub3Qgd29yayBjb3JyZWN0bHksdGhlICBzY2VuZSBkaXNwbGF5ZWQgb24g dGhlIHNjcmVlbiBpcyB0d2lua2xpbmcsYnV0IG9uIG9uZSBtYWNoaW5lIGl0IHdvcmtzIHdl bGwgLiBDYW4gYW55b25lIGhlbHAgbWUgPw0KICAgIA0KVGhhbmsgeW91LA0KWmVuZ0xpYW5n ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICANCiAgDQoNCiMgQ29weXJpZ2h0IChjKSAyMDAxLCBTdGFuZm9yZCBVbml2ZXJz aXR5DQoNCiMgQWxsIHJpZ2h0cyByZXNlcnZlZA0KIw0KIyBTZWUgdGhlIGZpbGUgTElDRU5T RS50eHQgZm9yIGluZm9ybWF0aW9uIG9uIHJlZGlzdHJpYnV0aW5nIHRoaXMgc29mdHdhcmUu DQoNCiMgRGVtb25zdHJhdGUgcGFyYWxsZWwgc3VibWlzc2lvbiB3aXRoIHNvcnQtZmlyc3Qg cmVuZGVyaW5nLg0KDQppbXBvcnQgc3lzDQpzeXMucGF0aC5hcHBlbmQoICIuLi9zZXJ2ZXIi ICkNCmZyb20gbW90aGVyc2hpcCBpbXBvcnQgKg0KDQppZiBsZW4oc3lzLmFyZ3YpID4gMToN CkRlbW8gPSBzeXMuYXJndlsxXQ0KZmlyc3RFeHRyYSA9IDINCmVsc2U6DQpEZW1vID0gJ3Bz dWJtaXRfY3J1dCcNCmZpcnN0RXh0cmEgPSAxDQoNCiMgQ29sbGVjdCByZW1haW5pbmcgY29t bWFuZCBsaW5lIHBhcmFtcyBhcyBwcm9ncmFtIG9wdGlvbnMNCkV4dHJhT3B0cyA9ICIiDQpm b3IgYXJnIGluIHN5cy5hcmd2W2ZpcnN0RXh0cmE6XToNCkV4dHJhT3B0cyArPSBhcmcgKyAi ICINCg0KRGVtbyA9IG9zLnBhdGguam9pbihjcmJpbmRpciwgRGVtbykNCk1PVEhFUlNISVAg PSBzb2NrZXQuZ2V0aG9zdG5hbWUoKQ0KDQojIEhvdyBtYW55IGRpc3BsYXkgdGlsZXMNClRJ TEVfQ09MUyA9IDINClRJTEVfUk9XUyA9IDIgDQoNCiMgUnVuIGNyc2VydmVyIGFuZCBjcmFw cGZha2VyIGF1dG9tYXRpY2FsbHk/DQpBVVRPU1RBUlQgPSAxDQpTSEVMTCA9ICIvdXNyL2Jp bi9yc2giDQpsb2NhbGN0YWcgPTAgDQpsb2NhbHN0YWcgPTANCg0KVGlsZVdpZHRoID0gMjAw DQpUaWxlSGVpZ2h0ID0gMjAwDQoNCk51bUFwcHMgPSAyDQoNClNlcnZlcnMgPSBbJ2xvY2Fs aG9zdCcsICdsb2NhbGhvc3QnLCdsb2NhbGhvc3QnLCdsb2NhbGhvc3QnXQ0KQ2xpZW50cyA9 IFsnc2VydmVyMScsICdzZXJ2ZXIxJywgJ3NlcnZlcjEnLCAnc2VydmVyMSddDQoNCnNlcnZl cm5vZGUgPSBbJ3NlcnZlcjEnLCdzZXJ2ZXIyJywnc2VydmVyMycsJ3NlcnZlcjQnXQ0KDQpE cmF3QmJveCA9IDANCkJ1Y2tldE1vZGUgPSAiVW5pZm9ybSBHcmlkIg0KDQojIENhbiByZW5k ZXIvcmVhZGJhY2sgd2luZG93cyBieSBkeW5hbWljYWxseSByZXNpemVkPw0KcmVzaXphYmxl ID0gMQ0KDQojIFNldCB0aGlzIHRvIHplcm8gdG8gd29yay1hcm91bmQgYSBwcm9ibGVtIHdp dGggQVRJJ3MgTGludXggZHJpdmVyDQpVc2VnbFhDaG9vc2VWaXN1YWwgPSAxDQoNCmNyID0g Q1IoKQ0KY3IuTVRVKCAxMCoxMDI0KjEwMjQgKQ0KDQojIFNldCB1cCB0aGUgY29udHJvbCBz ZXJ2ZXIgbm9kZQ0Kc2VydmVybm9kZTEyID0gQ1JOZXR3b3JrTm9kZShTZXJ2ZXJzWzBdKQ0K DQoNCiMgTm90ZTogZWFjaCBjbGllbnQgaGFzIHRoZSAtc3dhcCBmbGFnIGFuZCB3ZSB0ZWxs IHRoZSBzZXJ2ZXIgdG8gb25seQ0KIyBkbyBvbmUgU3dhcEJ1ZmZlcnMgaGVyZS4NCnNlcnZl cm5vZGUxMi5Db25mKCAnb25seV9zd2FwX29uY2UnLCAxICkNCnNlcnZlcm5vZGUxMi5Db25m KCAnc2hhcmVkX3dpbmRvd3MnLCAxICkNCnJlbmRlcnNwdSA9IFNQVSggJ3JlbmRlcicgKQ0K cmVuZGVyc3B1LkNvbmYoICd3aW5kb3dfZ2VvbWV0cnknLCBbNjAwLCA2MDAsIFRpbGVXaWR0 aCoyLCBUaWxlSGVpZ2h0KjJdICkNCnJlbmRlcnNwdS5Db25mKCdyZXNpemFibGUnLCByZXNp emFibGUpDQpyZW5kZXJzcHUuQ29uZigndHlwZScsICdhbHBoYScpDQpyZW5kZXJzcHUuQ29u ZigncmVuZGVyX3RvX2NydXRfd2luZG93JywgMSApDQpyZW5kZXJzcHUuQ29uZignZGVmYXVs dF92aXN1YWwnLCAncmdiLCBhbHBoYSwgZG91YmxlLCBkZXB0aCcpDQpyZW5kZXJzcHUuQ29u ZigndGl0bGUnLCJ0ZXN0ICIpDQpyZW5kZXJzcHUuQ29uZignc2hhcmVkX3dpbmRvd3MnLCAx KQ0KcmVuZGVyc3B1LkNvbmYoJ3VzZV9nbHhjaG9vc2V2aXN1YWwnLCBVc2VnbFhDaG9vc2VW aXN1YWwpOw0Kc2VydmVybm9kZTEyLkFkZFNQVSggcmVuZGVyc3B1ICkNCnNlcnZlcm5vZGUx Mi5BZGRUaWxlKCAwLCAwLCBUaWxlV2lkdGgqMiwgVGlsZUhlaWdodCoyICkNCiNjci5BZGRO b2RlKCBzZXJ2ZXJub2RlMTIgKQ0KDQoNCiNjcmVhdGUgYSBjcnV0c2VydmVyDQpjcnV0c2Vy dmVyID0gQ1JVVFNlcnZlck5vZGUoIFNlcnZlcnNbMF0gKQ0KY3J1dHNlcnZlci5Db25mKCd3 aW5kb3dfZ2VvbWV0cnknLCBbNTAwLCAxMCxUaWxlV2lkdGgqMiwgVGlsZUhlaWdodCoyXSAp DQpjcnV0c2VydmVyLkNvbmYoJ3RpdGxlJywidGVzdCAiKQ0KDQojIFNldCB1cCBuZXR3b3Jr IG5vZGVzDQpmb3Igcm93IGluIHJhbmdlKFRJTEVfUk9XUyk6DQpmb3IgY29sIGluIHJhbmdl KFRJTEVfQ09MUyk6DQppbmRleCA9IHJvdyAqIFRJTEVfQ09MUyArIGNvbA0Kc2VydmVybm9k ZVtpbmRleF0gPSBDUk5ldHdvcmtOb2RlKFNlcnZlcnNbaW5kZXhdKQ0Kc3B1ID0gU1BVKCdy ZWFkYmFjaycpDQpzcHUuQ29uZignd2luZG93X2dlb21ldHJ5JywgWyhyb3cpKlRpbGVXaWR0 aCwgKDEtY29sKSpUaWxlSGVpZ2h0LCBUaWxlV2lkdGgsIFRpbGVIZWlnaHRdKQ0Kc3B1LkNv bmYoJ2V4dHJhY3RfZGVwdGgnLCAxKQ0Kc3B1LkNvbmYoJ3R5cGUnLCAnYWxwaGEnKQ0Kc3B1 LkNvbmYoJ3NoYXJlZF93aW5kb3dzJywgMSkNCnNwdS5Db25mKCdkZWZhdWx0X3Zpc3VhbCcs ICdyZ2IsIGFscGhhLCBkb3VibGUsIGRlcHRoJykNCnNwdS5Db25mKCd1c2VfZ2x4Y2hvb3Nl dmlzdWFsJywgVXNlZ2xYQ2hvb3NlVmlzdWFsKTsNCnNwdS5Db25mKCd0aXRsZScsInRlc3Qg IikNCnNlcnZlcm5vZGVbaW5kZXhdLkFkZFNQVSggc3B1ICkNCnNwdSA9IFNQVSgncGFjaycp DQpzZXJ2ZXJub2RlW2luZGV4XS5BZGRTUFUoIHNwdSApDQpzcHUuQWRkU2VydmVyKCBzZXJ2 ZXJub2RlMTIsICd0Y3BpcCcsNzA5OSApDQpzZXJ2ZXJub2RlW2luZGV4XS5BZGRUaWxlKChy b3cpKlRpbGVXaWR0aCwgKGNvbCkqVGlsZUhlaWdodCwgVGlsZVdpZHRoLCBUaWxlSGVpZ2h0 ICkNCnNlcnZlcm5vZGVbaW5kZXhdLkNvbmYoJ3NoYXJlZF93aW5kb3dzJywgMSkNCg0KaWYg QVVUT1NUQVJUOg0KZW52ID0gIkxEX0xJQlJBUllfUEFUSD0iICsgY3JsaWJkaXINCnByb2cg PSBjcmJpbmRpciArICIvY3JzZXJ2ZXIgLW1vdGhlcnNoaXAgIiArIE1PVEhFUlNISVANCmlm IGxvY2Fsc3RhZzoNCnNlcnZlcm5vZGUuQXV0b1N0YXJ0KCBbU0hFTEwsDQpORVRIT1NUU1tp bmRleF0sDQoiL2Jpbi9zaCAtYyAnIiArIGVudiArICIgIiArIHByb2cgKyAiJyJdICkNCmVs c2U6DQojIElmIHlvdSB3YW50IG8gcnVuIGxvY2FsbHkgd2l0aCAvYmluL3NoLCB0cnkgdGhp czoNCnNlcnZlcm5vZGVbaW5kZXhdLkF1dG9TdGFydCggWyIvYmluL3NoIiwgIi1jIiwgZW52 ICsgIiAiICsgcHJvZ10gKQ0KY3IuQWRkTm9kZSggc2VydmVybm9kZVtpbmRleF0gKQ0KDQoj IFNldCB1cCBhcHAvY2xpZW50IG5vZGVzDQpmb3IgcmFuayBpbiByYW5nZSgwLCBOdW1BcHBz KToNCmFwcG5vZGUgPSBDUkFwcGxpY2F0aW9uTm9kZShDbGllbnRzW3JhbmtdKQ0KaWYgcmFu ayA9PSAwOg0KYXBwbm9kZS5TZXRBcHBsaWNhdGlvbiggJyVzIC1yYW5rIDAgLXNpemUgJWQg LWNsZWFyIC1zd2FwICVzJyAlIChEZW1vLCBOdW1BcHBzLCBFeHRyYU9wdHMpICkNCmVsc2U6 DQphcHBub2RlLlNldEFwcGxpY2F0aW9uKCAnJXMgLXJhbmsgJWQgLXNpemUgJWQgJXMnICUg KERlbW8sIHJhbmssIE51bUFwcHMsIEV4dHJhT3B0cykgKQ0KYXBwbm9kZS5TdGFydERpcigg Y3JiaW5kaXIgKQ0Kc3B1ID0gU1BVKCd0aWxlc29ydCcpDQpzcHUuQ29uZignZmFrZV93aW5k b3dfZGltcycsIFtUaWxlV2lkdGggKiAyLCBUaWxlSGVpZ2h0KjJdICkNCnNwdS5Db25mKCdk cmF3X2Jib3gnLCBEcmF3QmJveCkNCnNwdS5Db25mKCdidWNrZXRfbW9kZScsIEJ1Y2tldE1v ZGUpDQphcHBub2RlLkFkZFNQVSggc3B1ICkNCnNwdS5BZGRTZXJ2ZXIoIHNlcnZlcm5vZGVb MF0sIHByb3RvY29sPSd0Y3BpcCcsIHBvcnQ9NzAwMSApDQpzcHUuQWRkU2VydmVyKCBzZXJ2 ZXJub2RlWzFdLCBwcm90b2NvbD0ndGNwaXAnLCBwb3J0PTcwMDIgKQ0Kc3B1LkFkZFNlcnZl ciggc2VydmVybm9kZVsyXSwgcHJvdG9jb2w9J3RjcGlwJywgcG9ydD03MDAzICkNCnNwdS5B ZGRTZXJ2ZXIoIHNlcnZlcm5vZGVbM10sIHByb3RvY29sPSd0Y3BpcCcsIHBvcnQ9NzAxNCAp DQoNCmFwcG5vZGUuQWRkQ1JVVFNlcnZlciggY3J1dHNlcnZlciwgcHJvdG9jb2w9J3RjcGlw JywgcG9ydD05MDAwICkNCmlmIEFVVE9TVEFSVDoNCmVudiA9ICJMRF9MSUJSQVJZX1BBVEg9 IiArIGNybGliZGlyDQpwcm9nID0gY3JiaW5kaXIgKyAiL2NyYXBwZmFrZXIgLW1vdGhlcnNo aXAgIiArIE1PVEhFUlNISVANCmlmIGxvY2FsY3RhZzoNCmFwcG5vZGUuQXV0b1N0YXJ0KCBb U0hFTEwsICBBUFBIT1NULCAiL2Jpbi9zaCAtYyAnIiArIGVudiArICIgIiArIHByb2cgKyAi JyJdICkNCmVsc2U6DQojIElmIHlvdSB3YW50IG8gcnVuIGxvY2FsbHkgd2l0aCAvYmluL3No LCB0cnkgdGhpczoNCmFwcG5vZGUuQXV0b1N0YXJ0KCBbIi9iaW4vc2giLCAiLWMiLCBlbnYg KyAiICIgKyBwcm9nXSApDQpjci5BZGROb2RlKCBhcHBub2RlICkNCiNBdXRvIHN0YXJ0IGNy dXRzZXJ2ZXINCmlmIEFVVE9TVEFSVDoNCmVudiA9ICJMRF9MSUJSQVJZX1BBVEg9IiArIGNy bGliZGlyDQogICAgICAgcHJvZyA9IGNyYmluZGlyICsgIi9jcnV0c2VydmVyIC1tb3RoZXJz aGlwICIgKyBNT1RIRVJTSElQDQogICAgICAgaWYgbG9jYWxjdGFnOg0KICAgICAgICAgY3J1 dHNlcnZlci5BdXRvU3RhcnQoIFtTSEVMTCwgIEFQUEhPU1QsICIvYmluL3NoIC1jICciICsg ZW52ICsgIiAiICsgcHJvZyArICInIl0gKQ0KICAgICAgICBlbHNlOg0KICAgICAgICAjIElm IHlvdSB3YW50IG8gcnVuIGxvY2FsbHkgd2l0aCAvYmluL3NoLCB0cnkgdGhpczoNCiAgICAg ICAgIGNydXRzZXJ2ZXIuQXV0b1N0YXJ0KCBbIi9iaW4vc2giLCAiLWMiLCBlbnYgKyAiICIg KyBwcm9nXSApIA0KY3IuQWRkTm9kZSggY3J1dHNlcnZlciApDQojQXV0byBzdGFydCBjcnNl cnZlcg0KaWYgQVVUT1NUQVJUOg0KICAgICAgICBlbnYgPSAiTERfTElCUkFSWV9QQVRIPSIg KyBjcmxpYmRpcg0KICAgICAgICBwcm9nID0gY3JiaW5kaXIgKyAiL2Nyc2VydmVyIC1tb3Ro ZXJzaGlwICIgKyBNT1RIRVJTSElQDQogICAgICAgIGlmIGxvY2FsY3RhZzoNCiAgICAgICAg IHNlcnZlcm5vZGUxMi5BdXRvU3RhcnQoIFtTSEVMTCwgIEFQUEhPU1QsICIvYmluL3NoIC1j ICciICsgZW52ICsgIiAiICsgcHJvZyArICInIl0gKQ0KICAgICAgICBlbHNlOg0KICAgICAg ICAjIElmIHlvdSB3YW50IG8gcnVuIGxvY2FsbHkgd2l0aCAvYmluL3NoLCB0cnkgdGhpczoN CiAgICAgICAgIHNlcnZlcm5vZGUxMi5BdXRvU3RhcnQoIFsiL2Jpbi9zaCIsICItYyIsIGVu diArICIgIiArIHByb2ddICkNCmNyLkFkZE5vZGUoIHNlcnZlcm5vZGUxMiApDQpjci5Hbygp DQoNCg0KDQoNCg0KDQoNCj09PT09PT09PT09PT09PT09PT09PT09MjYzzOzPwtPKo63QxcC1 08rX1Neo0rU9PT09PT09PT09PT09PT09PT09PT09PQ0K |
|
From: <lia...@26...> - 2006-11-09 08:47:49
|
aGksYWxsOg0KDQpJJ20gIHNldHRpbmcgdXAgYSBtaW5pLWNsdXN0ZXIgb2YgZm91ciBtYWNo aW5lcyB0byB0ZXN0IENydXQgd2l0aCB0d28gYXBwbGljYXRpb24gY2xpZW50cy4odGhlIGFw cGxpY2F0aW9uIGNvZGUgaXMgcHN1Ym1pdCBpbiB0aGUgcHJvZ3Mgb2YgY3ItMS44KS5Gb2xs b3dpbmcgaXMgdGhlIGNvbmZpZ3VyZSBmaWxlLkJ1dCB0aGUgc2VydmVyIG5vZGUgcmVuZGVy aW5nIGRvZXMgbm90IHdvcmsgY29ycmVjdGx5KHRoZSBzY2VuZSBkaXNwbGF5ZWQgb24gdGhl IHNjcmVlbiBpcyB0d2lua2xpbmcpLiBDYW4gYW55b25lIGhlbHAgbWUgPw0KICAgIA0KVGhh bmsgeW91LA0KWmVuZ0xpYW5nICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgDQoNCiMgQ29weXJpZ2h0IChjKSAyMDAx LCBTdGFuZm9yZCBVbml2ZXJzaXR5DQoNCiMgQWxsIHJpZ2h0cyByZXNlcnZlZA0KIw0KIyBT ZWUgdGhlIGZpbGUgTElDRU5TRS50eHQgZm9yIGluZm9ybWF0aW9uIG9uIHJlZGlzdHJpYnV0 aW5nIHRoaXMgc29mdHdhcmUuDQoNCiMgRGVtb25zdHJhdGUgcGFyYWxsZWwgc3VibWlzc2lv biB3aXRoIHNvcnQtZmlyc3QgcmVuZGVyaW5nLg0KDQppbXBvcnQgc3lzDQpzeXMucGF0aC5h cHBlbmQoICIuLi9zZXJ2ZXIiICkNCmZyb20gbW90aGVyc2hpcCBpbXBvcnQgKg0KDQppZiBs ZW4oc3lzLmFyZ3YpID4gMToNCglEZW1vID0gc3lzLmFyZ3ZbMV0NCglmaXJzdEV4dHJhID0g Mg0KZWxzZToNCglEZW1vID0gJ3BzdWJtaXRfY3J1dCcNCglmaXJzdEV4dHJhID0gMQ0KCQ0K IyBDb2xsZWN0IHJlbWFpbmluZyBjb21tYW5kIGxpbmUgcGFyYW1zIGFzIHByb2dyYW0gb3B0 aW9ucw0KRXh0cmFPcHRzID0gIiINCmZvciBhcmcgaW4gc3lzLmFyZ3ZbZmlyc3RFeHRyYTpd Og0KCUV4dHJhT3B0cyArPSBhcmcgKyAiICINCg0KRGVtbyA9IG9zLnBhdGguam9pbihjcmJp bmRpciwgRGVtbykNCk1PVEhFUlNISVAgPSBzb2NrZXQuZ2V0aG9zdG5hbWUoKQ0KDQojIEhv dyBtYW55IGRpc3BsYXkgdGlsZXMNClRJTEVfQ09MUyA9IDINClRJTEVfUk9XUyA9IDIgDQoN CiMgUnVuIGNyc2VydmVyIGFuZCBjcmFwcGZha2VyIGF1dG9tYXRpY2FsbHk/DQpBVVRPU1RB UlQgPSAxDQpTSEVMTCA9ICIvdXNyL2Jpbi9yc2giDQpsb2NhbGN0YWcgPTAgDQpsb2NhbHN0 YWcgPTANCg0KVGlsZVdpZHRoID0gMjAwDQpUaWxlSGVpZ2h0ID0gMjAwDQoNCk51bUFwcHMg PSAyDQoNClNlcnZlcnMgPSBbJ2xvY2FsaG9zdCcsICdsb2NhbGhvc3QnLCdsb2NhbGhvc3Qn LCdsb2NhbGhvc3QnXQ0KQ2xpZW50cyA9IFsnc2VydmVyMScsICdzZXJ2ZXIxJywgJ3NlcnZl cjEnLCAnc2VydmVyMSddDQoNCnNlcnZlcm5vZGUgPSBbJ3NlcnZlcjEnLCdzZXJ2ZXIyJywn c2VydmVyMycsJ3NlcnZlcjQnXQ0KDQpEcmF3QmJveCA9IDANCkJ1Y2tldE1vZGUgPSAiVW5p Zm9ybSBHcmlkIg0KDQojIENhbiByZW5kZXIvcmVhZGJhY2sgd2luZG93cyBieSBkeW5hbWlj YWxseSByZXNpemVkPw0KcmVzaXphYmxlID0gMQ0KDQojIFNldCB0aGlzIHRvIHplcm8gdG8g d29yay1hcm91bmQgYSBwcm9ibGVtIHdpdGggQVRJJ3MgTGludXggZHJpdmVyDQpVc2VnbFhD aG9vc2VWaXN1YWwgPSAxDQoNCmNyID0gQ1IoKQ0KY3IuTVRVKCAxMCoxMDI0KjEwMjQgKQ0K DQojIFNldCB1cCB0aGUgY29udHJvbCBzZXJ2ZXIgbm9kZQ0Kc2VydmVybm9kZTEyID0gQ1JO ZXR3b3JrTm9kZShTZXJ2ZXJzWzBdKQ0KDQoNCiMgTm90ZTogZWFjaCBjbGllbnQgaGFzIHRo ZSAtc3dhcCBmbGFnIGFuZCB3ZSB0ZWxsIHRoZSBzZXJ2ZXIgdG8gb25seQ0KIyBkbyBvbmUg U3dhcEJ1ZmZlcnMgaGVyZS4NCnNlcnZlcm5vZGUxMi5Db25mKCAnb25seV9zd2FwX29uY2Un LCAxICkNCnNlcnZlcm5vZGUxMi5Db25mKCAnc2hhcmVkX3dpbmRvd3MnLCAxICkNCnJlbmRl cnNwdSA9IFNQVSggJ3JlbmRlcicgKQ0KcmVuZGVyc3B1LkNvbmYoICd3aW5kb3dfZ2VvbWV0 cnknLCBbNjAwLCA2MDAsIFRpbGVXaWR0aCoyLCBUaWxlSGVpZ2h0KjJdICkNCnJlbmRlcnNw dS5Db25mKCdyZXNpemFibGUnLCByZXNpemFibGUpDQpyZW5kZXJzcHUuQ29uZigndHlwZScs ICdhbHBoYScpDQpyZW5kZXJzcHUuQ29uZigncmVuZGVyX3RvX2NydXRfd2luZG93JywgMSAp DQpyZW5kZXJzcHUuQ29uZignZGVmYXVsdF92aXN1YWwnLCAncmdiLCBhbHBoYSwgZG91Ymxl LCBkZXB0aCcpDQpyZW5kZXJzcHUuQ29uZigndGl0bGUnLCJ0ZXN0ICIpDQpyZW5kZXJzcHUu Q29uZignc2hhcmVkX3dpbmRvd3MnLCAxKQ0KcmVuZGVyc3B1LkNvbmYoJ3VzZV9nbHhjaG9v c2V2aXN1YWwnLCBVc2VnbFhDaG9vc2VWaXN1YWwpOw0Kc2VydmVybm9kZTEyLkFkZFNQVSgg cmVuZGVyc3B1ICkNCnNlcnZlcm5vZGUxMi5BZGRUaWxlKCAwLCAwLCBUaWxlV2lkdGgqMiwg VGlsZUhlaWdodCoyICkNCiNjci5BZGROb2RlKCBzZXJ2ZXJub2RlMTIgKQ0KDQoNCiNjcmVh dGUgYSBjcnV0c2VydmVyDQpjcnV0c2VydmVyID0gQ1JVVFNlcnZlck5vZGUoIFNlcnZlcnNb MF0gKQ0KY3J1dHNlcnZlci5Db25mKCd3aW5kb3dfZ2VvbWV0cnknLCBbNTAwLCAxMCxUaWxl V2lkdGgqMiwgVGlsZUhlaWdodCoyXSApDQpjcnV0c2VydmVyLkNvbmYoJ3RpdGxlJywidGVz dCAiKQ0KDQojIFNldCB1cCBuZXR3b3JrIG5vZGVzDQpmb3Igcm93IGluIHJhbmdlKFRJTEVf Uk9XUyk6DQoJZm9yIGNvbCBpbiByYW5nZShUSUxFX0NPTFMpOg0KCQlpbmRleCA9IHJvdyAq IFRJTEVfQ09MUyArIGNvbA0KCQlzZXJ2ZXJub2RlW2luZGV4XSA9IENSTmV0d29ya05vZGUo U2VydmVyc1tpbmRleF0pDQoJCXNwdSA9IFNQVSgncmVhZGJhY2snKQ0KCQlzcHUuQ29uZign d2luZG93X2dlb21ldHJ5JywgWyhyb3cpKlRpbGVXaWR0aCwgKDEtY29sKSpUaWxlSGVpZ2h0 LCBUaWxlV2lkdGgsIFRpbGVIZWlnaHRdKQ0KCQlzcHUuQ29uZignZXh0cmFjdF9kZXB0aCcs IDEpDQoJCXNwdS5Db25mKCd0eXBlJywgJ2FscGhhJykNCgkJc3B1LkNvbmYoJ3NoYXJlZF93 aW5kb3dzJywgMSkNCgkJc3B1LkNvbmYoJ2RlZmF1bHRfdmlzdWFsJywgJ3JnYiwgYWxwaGEs IGRvdWJsZSwgZGVwdGgnKQ0KCQlzcHUuQ29uZigndXNlX2dseGNob29zZXZpc3VhbCcsIFVz ZWdsWENob29zZVZpc3VhbCk7DQoJCXNwdS5Db25mKCd0aXRsZScsInRlc3QgIikNCgkJc2Vy dmVybm9kZVtpbmRleF0uQWRkU1BVKCBzcHUgKQ0KCQlzcHUgPSBTUFUoJ3BhY2snKQ0KCQlz ZXJ2ZXJub2RlW2luZGV4XS5BZGRTUFUoIHNwdSApDQoJCXNwdS5BZGRTZXJ2ZXIoIHNlcnZl cm5vZGUxMiwgJ3RjcGlwJyw3MDk5ICkNCgkJc2VydmVybm9kZVtpbmRleF0uQWRkVGlsZSgo cm93KSpUaWxlV2lkdGgsIChjb2wpKlRpbGVIZWlnaHQsIFRpbGVXaWR0aCwgVGlsZUhlaWdo dCApDQoJCXNlcnZlcm5vZGVbaW5kZXhdLkNvbmYoJ3NoYXJlZF93aW5kb3dzJywgMSkNCg0K CQlpZiBBVVRPU1RBUlQ6DQoJCQllbnYgPSAiTERfTElCUkFSWV9QQVRIPSIgKyBjcmxpYmRp cg0KCQkJcHJvZyA9IGNyYmluZGlyICsgIi9jcnNlcnZlciAtbW90aGVyc2hpcCAiICsgTU9U SEVSU0hJUA0KCQkJaWYgbG9jYWxzdGFnOg0KCQkJCXNlcnZlcm5vZGUuQXV0b1N0YXJ0KCBb U0hFTEwsDQoJCQkJCQkJIE5FVEhPU1RTW2luZGV4XSwNCgkJCQkJCQkgIi9iaW4vc2ggLWMg JyIgKyBlbnYgKyAiICIgKyBwcm9nICsgIiciXSApDQoJCQllbHNlOg0KCQkJIyBJZiB5b3Ug d2FudCBvIHJ1biBsb2NhbGx5IHdpdGggL2Jpbi9zaCwgdHJ5IHRoaXM6DQoJCQkJc2VydmVy bm9kZVtpbmRleF0uQXV0b1N0YXJ0KCBbIi9iaW4vc2giLCAiLWMiLCBlbnYgKyAiICIgKyBw cm9nXSApDQoJCWNyLkFkZE5vZGUoIHNlcnZlcm5vZGVbaW5kZXhdICkNCg0KIyBTZXQgdXAg YXBwL2NsaWVudCBub2Rlcw0KZm9yIHJhbmsgaW4gcmFuZ2UoMCwgTnVtQXBwcyk6DQoJYXBw bm9kZSA9IENSQXBwbGljYXRpb25Ob2RlKENsaWVudHNbcmFua10pDQoJaWYgcmFuayA9PSAw Og0KCQlhcHBub2RlLlNldEFwcGxpY2F0aW9uKCAnJXMgLXJhbmsgMCAtc2l6ZSAlZCAtY2xl YXIgLXN3YXAgJXMnICUgKERlbW8sIE51bUFwcHMsIEV4dHJhT3B0cykgKQ0KCWVsc2U6DQoJ CWFwcG5vZGUuU2V0QXBwbGljYXRpb24oICclcyAtcmFuayAlZCAtc2l6ZSAlZCAlcycgJSAo RGVtbywgcmFuaywgTnVtQXBwcywgRXh0cmFPcHRzKSApDQoJYXBwbm9kZS5TdGFydERpcigg Y3JiaW5kaXIgKQ0KCXNwdSA9IFNQVSgndGlsZXNvcnQnKQ0KCXNwdS5Db25mKCdmYWtlX3dp bmRvd19kaW1zJywgW1RpbGVXaWR0aCAqIDIsIFRpbGVIZWlnaHQqMl0gKQ0KCXNwdS5Db25m KCdkcmF3X2Jib3gnLCBEcmF3QmJveCkNCglzcHUuQ29uZignYnVja2V0X21vZGUnLCBCdWNr ZXRNb2RlKQ0KCWFwcG5vZGUuQWRkU1BVKCBzcHUgKQ0KCXNwdS5BZGRTZXJ2ZXIoIHNlcnZl cm5vZGVbMF0sIHByb3RvY29sPSd0Y3BpcCcsIHBvcnQ9NzAwMSApDQoJc3B1LkFkZFNlcnZl ciggc2VydmVybm9kZVsxXSwgcHJvdG9jb2w9J3RjcGlwJywgcG9ydD03MDAyICkNCglzcHUu QWRkU2VydmVyKCBzZXJ2ZXJub2RlWzJdLCBwcm90b2NvbD0ndGNwaXAnLCBwb3J0PTcwMDMg KQ0KCXNwdS5BZGRTZXJ2ZXIoIHNlcnZlcm5vZGVbM10sIHByb3RvY29sPSd0Y3BpcCcsIHBv cnQ9NzAxNCApDQoNCglhcHBub2RlLkFkZENSVVRTZXJ2ZXIoIGNydXRzZXJ2ZXIsIHByb3Rv Y29sPSd0Y3BpcCcsIHBvcnQ9OTAwMCApDQoJaWYgQVVUT1NUQVJUOg0KCQllbnYgPSAiTERf TElCUkFSWV9QQVRIPSIgKyBjcmxpYmRpcg0KCQlwcm9nID0gY3JiaW5kaXIgKyAiL2NyYXBw ZmFrZXIgLW1vdGhlcnNoaXAgIiArIE1PVEhFUlNISVANCgkJaWYgbG9jYWxjdGFnOg0KCQkJ YXBwbm9kZS5BdXRvU3RhcnQoIFtTSEVMTCwgIEFQUEhPU1QsICIvYmluL3NoIC1jICciICsg ZW52ICsgIiAiICsgcHJvZyArICInIl0gKQ0KCQllbHNlOg0KCQkjIElmIHlvdSB3YW50IG8g cnVuIGxvY2FsbHkgd2l0aCAvYmluL3NoLCB0cnkgdGhpczoNCgkJCWFwcG5vZGUuQXV0b1N0 YXJ0KCBbIi9iaW4vc2giLCAiLWMiLCBlbnYgKyAiICIgKyBwcm9nXSApDQoJY3IuQWRkTm9k ZSggYXBwbm9kZSApDQojQXV0byBzdGFydCBjcnV0c2VydmVyDQppZiBBVVRPU1RBUlQ6DQoJ ZW52ID0gIkxEX0xJQlJBUllfUEFUSD0iICsgY3JsaWJkaXINCiAgICAgICAJcHJvZyA9IGNy YmluZGlyICsgIi9jcnV0c2VydmVyIC1tb3RoZXJzaGlwICIgKyBNT1RIRVJTSElQDQogICAg ICAgCWlmIGxvY2FsY3RhZzoNCiAgICAgICAgCWNydXRzZXJ2ZXIuQXV0b1N0YXJ0KCBbU0hF TEwsICBBUFBIT1NULCAiL2Jpbi9zaCAtYyAnIiArIGVudiArICIgIiArIHByb2cgKyAiJyJd ICkNCiAgICAgICAgZWxzZToNCiAgICAgICAgIyBJZiB5b3Ugd2FudCBvIHJ1biBsb2NhbGx5 IHdpdGggL2Jpbi9zaCwgdHJ5IHRoaXM6DQogICAgICAgIAljcnV0c2VydmVyLkF1dG9TdGFy dCggWyIvYmluL3NoIiwgIi1jIiwgZW52ICsgIiAiICsgcHJvZ10gKSANCmNyLkFkZE5vZGUo IGNydXRzZXJ2ZXIgKQ0KI0F1dG8gc3RhcnQgY3JzZXJ2ZXINCmlmIEFVVE9TVEFSVDoNCiAg ICAgICAgZW52ID0gIkxEX0xJQlJBUllfUEFUSD0iICsgY3JsaWJkaXINCiAgICAgICAgcHJv ZyA9IGNyYmluZGlyICsgIi9jcnNlcnZlciAtbW90aGVyc2hpcCAiICsgTU9USEVSU0hJUA0K ICAgICAgICBpZiBsb2NhbGN0YWc6DQogICAgICAgIAlzZXJ2ZXJub2RlMTIuQXV0b1N0YXJ0 KCBbU0hFTEwsICBBUFBIT1NULCAiL2Jpbi9zaCAtYyAnIiArIGVudiArICIgIiArIHByb2cg KyAiJyJdICkNCiAgICAgICAgZWxzZToNCiAgICAgICAgIyBJZiB5b3Ugd2FudCBvIHJ1biBs b2NhbGx5IHdpdGggL2Jpbi9zaCwgdHJ5IHRoaXM6DQogICAgICAgIAlzZXJ2ZXJub2RlMTIu QXV0b1N0YXJ0KCBbIi9iaW4vc2giLCAiLWMiLCBlbnYgKyAiICIgKyBwcm9nXSApDQpjci5B ZGROb2RlKCBzZXJ2ZXJub2RlMTIgKQ0KY3IuR28oKQ0KDQoNCg0KDQoNCg0KPT09PT09PT09 PT09PT09PT09PT09PT0yNjPM7M/C08qjrdDFwLXTytfU16jStT09PT09PT09PT09PT09PT09 PT09PT09DQo= |
|
From: Paul N. <Pau...@Su...> - 2006-10-29 20:56:56
|
Hi Brian, You were spot on, it was that we had 256*1024 MTU size in the config file, which would be OK if we had IB set up, but needed to be reduced for GbE. Many thanks, Paul. Brian Paul wrote: > Paul Needle wrote: >> Thanks Brian for your response. >> >> We put together a DMX config today and used the render_to_app_window >> as part of the dmx.conf, which solved point 1. However, we now have >> an issue where the app hangs for about 5 seconds and then works fine >> for about another 5 seconds, then hangs again, etc. It could be to do >> with using GbE, as we are waiting for Infiniband switches, etc. >> However, what doesn't seem to add up is that when running VMD over >> DMX (app on master, rendered on slave) and not Chromium, we get good >> performance, however, once you put Chromium into the mix, the >> performance issues outlined above occur. >> >> Any pointers as to how to best debug what is going on would be much >> appreciated. > > Hmmm, that's weird. I'd probably run with gdb, interupt the program > during one of the pauses, and see where I am, then maybe add some > instrumentation to see where the time is going. > > Might also experiment with a smaller/larger MTU in the .conf file. > > -Brian |
|
From: Brian P. <bri...@tu...> - 2006-10-26 23:05:08
|
Paul Needle wrote: > Thanks Brian for your response. > > We put together a DMX config today and used the render_to_app_window as > part of the dmx.conf, which solved point 1. However, we now have an > issue where the app hangs for about 5 seconds and then works fine for > about another 5 seconds, then hangs again, etc. It could be to do with > using GbE, as we are waiting for Infiniband switches, etc. However, what > doesn't seem to add up is that when running VMD over DMX (app on master, > rendered on slave) and not Chromium, we get good performance, however, > once you put Chromium into the mix, the performance issues outlined > above occur. > > Any pointers as to how to best debug what is going on would be much > appreciated. Hmmm, that's weird. I'd probably run with gdb, interupt the program during one of the pauses, and see where I am, then maybe add some instrumentation to see where the time is going. Might also experiment with a smaller/larger MTU in the .conf file. -Brian |
|
From: Paul N. <Pau...@Su...> - 2006-10-25 21:15:04
|
Thanks Brian for your response. We put together a DMX config today and used the render_to_app_window as part of the dmx.conf, which solved point 1. However, we now have an issue where the app hangs for about 5 seconds and then works fine for about another 5 seconds, then hangs again, etc. It could be to do with using GbE, as we are waiting for Infiniband switches, etc. However, what doesn't seem to add up is that when running VMD over DMX (app on master, rendered on slave) and not Chromium, we get good performance, however, once you put Chromium into the mix, the performance issues outlined above occur. Any pointers as to how to best debug what is going on would be much appreciated. Kind regards, Paul. Brian Paul wrote: > Paul Needle wrote: >> Hi, >> When I try to run applications (VMD/OpenSceneGraph) through Chromium, >> I have a few issues I can't work through: >> 1. Chromium splits the mouse control of the application into a >> separate window, with the actual display window being shown full >> screen separately. > > The 'render_to_app_window' option can be used to tell Chromium to > render back into the original application window. > > >> 2. Even though I am using the 'fullscreen' option from the render spu >> and even though the actual display window is full screen, the actual >> images only show up on a quarter of the screen. > > The render SPU is just using whatever viewport parameters the > application gives it. So, the viewport size in the render SPU window > is probably equal to the app window's size. > > With the tilesort SPU you can scale up rendering to match the render > SPU's window size. > > >> 3. Chromium can't interpose on scripts as easily as binaries, you >> need to mess around with the LD_LIBRARY_PATH variable within the >> application script (this one is not so much of a problem, as we have >> found a workaround more or less for this). > > Yeah, the only alternative to hacking the shell script is to put all > the Chromium libs in a standard location (like /usr/local/lib/) and/or > setting up various symlinks. > > -Brian |
|
From: Brian P. <bri...@tu...> - 2006-10-25 15:23:43
|
Paul Needle wrote: > Hi, > > When I try to run applications (VMD/OpenSceneGraph) through Chromium, I > have a few issues I can't work through: > > 1. Chromium splits the mouse control of the application into a separate > window, with the actual display window being shown full screen separately. The 'render_to_app_window' option can be used to tell Chromium to render back into the original application window. > 2. Even though I am using the 'fullscreen' option from the render spu > and even though the actual display window is full screen, the actual > images only show up on a quarter of the screen. The render SPU is just using whatever viewport parameters the application gives it. So, the viewport size in the render SPU window is probably equal to the app window's size. With the tilesort SPU you can scale up rendering to match the render SPU's window size. > 3. Chromium can't interpose on scripts as easily as binaries, you need > to mess around with the LD_LIBRARY_PATH variable within the application > script (this one is not so much of a problem, as we have found a > workaround more or less for this). Yeah, the only alternative to hacking the shell script is to put all the Chromium libs in a standard location (like /usr/local/lib/) and/or setting up various symlinks. -Brian |
|
From: Paul N. <Pau...@Su...> - 2006-10-23 18:08:23
|
Hi,
When I try to run applications (VMD/OpenSceneGraph) through Chromium, I
have a few issues I can't work through:
1. Chromium splits the mouse control of the application into a separate
window, with the actual display window being shown full screen separately.
2. Even though I am using the 'fullscreen' option from the render spu
and even though the actual display window is full screen, the actual
images only show up on a quarter of the screen.
3. Chromium can't interpose on scripts as easily as binaries, you need
to mess around with the LD_LIBRARY_PATH variable within the application
script (this one is not so much of a problem, as we have found a
workaround more or less for this).
I have included my .conf file below.
Many thanks,
Paul.
# Copyright (c) 2001, Stanford University
# All rights reserved
#
# See the file LICENSE.txt for information on redistributing this software.
import sys
sys.path.append( '../server' )
from mothership import *
if len(sys.argv) > 3 or len(sys.argv) < 2:
print 'Usage: %s <demo> [spu]' % sys.argv[0]
sys.exit(-1)
demo = sys.argv[1]
if len(sys.argv) == 3:
clientspuname = sys.argv[2]
else:
clientspuname = 'pack'
server_spu = SPU( 'render' )
client_spu = SPU( clientspuname )
W = 1280
H = 1024
server_spu.Conf( 'window_geometry', [0, 0, W, H] )
server_spu.Conf( 'fullscreen', 1)
server_spu.Conf( 'swap_master_url', "" )
#client_spu.Conf( 'draw_bbox', 1 )
server_node = CRNetworkNode( 'visdemo' )
#sps = SPU('print')
#sps.Conf('log_file', 'slog')
#server_node.AddSPU( sps )
server_node.AddSPU( server_spu )
if (clientspuname == 'tilesort' ):
server_node.AddTile( 0, 0, W, H )
client_node = CRApplicationNode( 'vismaster' )
#client_node.AddSPU( SPU('expando') )
#ps = SPU('print')
#ps.Conf('log_file', 'log')
#client_node.AddSPU( ps )
client_node.AddSPU( client_spu )
client_spu.AddServer( server_node, 'tcpip' )
client_node.SetApplication( demo )
client_node.StartDir( crbindir )
#client_node.StartDir( "/home/brian/51/tests/" )
cr = CR()
cr.MTU( 1024*1024 )
cr.AddNode( client_node )
cr.AddNode( server_node )
cr.Go()
|
|
From: Paul M. <p.e...@ru...> - 2006-10-19 08:00:53
|
Hello Jonathan, Jonathan Pierce wrote: > I should preface this by saying I'm completely new to Chromium. I'm > planning on setting up a mini-cluster of four machines just to test > it out and get my feet wet before committing to any large-scale > projects. One of the things I was wondering is whether or not there > would be any improvement in using Nvidia cards with g-sync > capabilities, and whether or not anything extra would need to be I tested the synchronized swapping that NVidia provides through GLX extensions with Chromium, but either the API's have changed too much or I'm doing something wrong, but I couldn't get them to work. The calls to the extensions are present in the Chromium code, though, however some of them fail. > configured within Chromium. I dug through the documentation a > little, but wasn't able to find anything about it. The settings related to NVidia swap-locking can be set as options to the Render SPU. I do intend to pick this up again in the near future, but if you have any interesting experiences yourself, I'd be interested to hear them. Regards, Paul PS Are you using the extensions with any other (non-chromium) application? > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Chromium-users mailing list > Chr...@li... > https://lists.sourceforge.net/lists/listinfo/chromium-users -- Paul Melis VR Specialist, Center for High-Performance Computing & Visualization, University of Groningen, The Netherlands T: +31 50 363 9298 E: p.e...@ru... W: http://www.rug.nl/rc/hpcv/index |
|
From: Jonathan P. <jon...@lo...> - 2006-10-19 01:04:32
|
Hi All, I should preface this by saying I'm completely new to Chromium. I'm planning on setting up a mini-cluster of four machines just to test it out and get my feet wet before committing to any large-scale projects. One of the things I was wondering is whether or not there would be any improvement in using Nvidia cards with g-sync capabilities, and whether or not anything extra would need to be configured within Chromium. I dug through the documentation a little, but wasn't able to find anything about it. Thank you, Jonathan |
|
From: Yusuke T. <yus...@ai...> - 2006-09-29 12:40:24
|
Hi, Brian,
> Yusuke Tanimura wrote:
> > Hi, Brian and Joseph,
> >
> > Thanks for your reply.
> >
> > I added 'array' spu to clientnode in my autodmx.conf but the image is
> > still not clear. I attached a capture image of my screens.
> >
> > clientnode = CRApplicationNode( )
> > clientnode.SetApplication( program )
> > + clientnode.AddSPU( SPU('array') )
> > clientnode.AddSPU( tilesortspu )
> > clientnode.Conf('track_window_size', 1)
> > clientnode.Conf('track_window_position', 1)
> >
> > Is this a resoluation problem?
>
> I'd guess it's a bug in the tilesort SPU. Maybe related to texture
> level of detail bias.
>
> I don't have time to investigate, sorry.
>
> -Brian
Thanks for your reply. I will keep watching this issue and let you
know if I can solve the problem.
---
Yusuke Tanimura
Grid Technology Research Center
National Institute of AIST, Japan
|
|
From: yun <yu...@nc...> - 2006-09-28 03:58:46
|
Dear All,
I download cr-1.9 and setup whole environment of tiled display.
Everything is ok to show application on tiled display.
When I try to display the application to remote machine, it can't work.
I use "DISPLAY={IP}:0 ./crappfaker" to load application
The original application can be shown on remote machine, but chromium screen
be shown, too.
I just want the original application to be shown on remote machine, and the
chromium screen still be shown on render machine (tiled display).
Is there any idea to solve it?
Best Regards,
--
Max Yu
Nation Center for High-Performance Computing, Taiwan
|
|
From: Brian P. <bri...@tu...> - 2006-09-27 14:03:02
|
Yusuke Tanimura wrote:
> Hi, Brian and Joseph,
>
> Thanks for your reply.
>
> I added 'array' spu to clientnode in my autodmx.conf but the image is
> still not clear. I attached a capture image of my screens.
>
> clientnode = CRApplicationNode( )
> clientnode.SetApplication( program )
> + clientnode.AddSPU( SPU('array') )
> clientnode.AddSPU( tilesortspu )
> clientnode.Conf('track_window_size', 1)
> clientnode.Conf('track_window_position', 1)
>
> Is this a resoluation problem?
I'd guess it's a bug in the tilesort SPU. Maybe related to texture
level of detail bias.
I don't have time to investigate, sorry.
-Brian
|
|
From: Daniel E. S. <dan...@gm...> - 2006-09-22 20:29:36
|
I have tracked the problem down farther.
When I use buGLe to look at the GL stream coming from my custom server
application I don't actually see any of the GL calls that are being made
over the wire... I had some other GL calls for drawing other things that
confused me and I thought those were the application's GL stream.
Any ideas on how to capture all GL calls from the custom server that mixes
GL calls from the server program and those that are coming off the wire as
well?
-Dan
On 9/22/06, Daniel E. Shipton <dan...@gm...> wrote:
>
> Hello all,
>
> I have an application that is processing the crServer loop by hand. It
> looks like so...
> NOTE: has_swapped gets set to 1 when glXSwapBuffers is seen within the
> stream.
> also, the glEnables are to explain my example
>
> // Draw graphics off the GL stream
> glPushMatrix();
> glEnable(GL_LIGHTING);
> glEnable(GL_LIGHTING);
> glEnable(GL_LIGHTING);
> while (cr_server.has_swapped != 1)
> {
> if(cr_server.run_queue != NULL)
> {
> crServerServiceClients();
> }
> }
> cr_server.has_swapped = 0;
> glDisable(GL_LIGHTING);
> glDisable(GL_LIGHTING);
> glDisable(GL_LIGHTING);
> glPopMatrix();
>
> When the code is compiled and ran the buGLe log shows:
>
> trace.call: glPushMatrix()
> trace.call: glEnable(GL_LIGHTING)
> trace.call: glEnable(GL_LIGHTING)
> trace.call: glEnable(GL_LIGHTING) <-- Over the wire drawing should
> begin here.
> trace.call: glDisable(GL_LIGHTING)
> trace.call: glDisable(GL_LIGHTING)
> trace.call: glDisable(GL_LIGHTING)
> trace.call: glPopMatrix()
> trace.call: glPushAttrib(GL_ALL_ATTRIB_BITS) <-- but begins here...
> trace.call: glGetBooleanv(GL_LIGHTING, 0x43c06bbb -> GL_FALSE)
> trace.call: glGetBooleanv(GL_LIGHT0, 0x43c06bba -> GL_TRUE)
> trace.call: glMaterialfv(GL_FRONT, GL_AMBIENT, 0x43c06ba0 -> { 0.1, 0.1,
> 0.1, 1 })
> trace.call: glMaterialfv(GL_FRONT, GL_SHININESS, 0x43c06b90 -> 50)
> trace.call: glMaterialfv(GL_FRONT, GL_SPECULAR, 0x43c06b70 -> { 1, 1, 1, 1
> })
> trace.call: glMaterialfv(GL_FRONT, GL_DIFFUSE, 0x43c06b80 -> { 0.7, 0.7,
> 0.7, 1 })
> trace.call: glColorMaterial(GL_FRONT_AND_BACK, GL_AMBIENT_AND_DIFFUSE)
> trace.call: glEnable(GL_COLOR_MATERIAL)
> trace.call: glDisable(GL_TEXTURE_2D)
> trace.call: glDisable(GL_TEXTURE_1D)
> trace.call: glPushMatrix()
> trace.call: glLoadIdentity()
> trace.call: glBegin(GL_LINES)
> trace.call: glColor3f(1, 0, 0)
> trace.call: glVertex3fv(0x43c06b30 -> { 0, 0, 0 })
> trace.call: glVertex3fv(0x43c06b60 -> { 3.28, 0, 0 })
> trace.call: glColor3f(0, 1, 0)
> trace.call: glVertex3fv(0x43c06b30 -> { 0, 0, 0 })
> .....
>
> I tried calling getNextClient with GL_TRUE (block)...but it had no effect.
>
>
> So my question is how to make sure that the stream has been deserialized
> into GL calls before I can continue making GL calls?
>
> -Dan
>
>
|
|
From: Daniel E. S. <dan...@gm...> - 2006-09-22 16:21:55
|
Hello all,
I have an application that is processing the crServer loop by hand. It
looks like so...
NOTE: has_swapped gets set to 1 when glXSwapBuffers is seen within the
stream.
also, the glEnables are to explain my example
// Draw graphics off the GL stream
glPushMatrix();
glEnable(GL_LIGHTING);
glEnable(GL_LIGHTING);
glEnable(GL_LIGHTING);
while (cr_server.has_swapped != 1)
{
if(cr_server.run_queue != NULL)
{
crServerServiceClients();
}
}
cr_server.has_swapped = 0;
glDisable(GL_LIGHTING);
glDisable(GL_LIGHTING);
glDisable(GL_LIGHTING);
glPopMatrix();
When the code is compiled and ran the buGLe log shows:
trace.call: glPushMatrix()
trace.call: glEnable(GL_LIGHTING)
trace.call: glEnable(GL_LIGHTING)
trace.call: glEnable(GL_LIGHTING) <-- Over the wire drawing should begin
here.
trace.call: glDisable(GL_LIGHTING)
trace.call: glDisable(GL_LIGHTING)
trace.call: glDisable(GL_LIGHTING)
trace.call: glPopMatrix()
trace.call: glPushAttrib(GL_ALL_ATTRIB_BITS) <-- but begins here...
trace.call: glGetBooleanv(GL_LIGHTING, 0x43c06bbb -> GL_FALSE)
trace.call: glGetBooleanv(GL_LIGHT0, 0x43c06bba -> GL_TRUE)
trace.call: glMaterialfv(GL_FRONT, GL_AMBIENT, 0x43c06ba0 -> { 0.1, 0.1, 0.1,
1 })
trace.call: glMaterialfv(GL_FRONT, GL_SHININESS, 0x43c06b90 -> 50)
trace.call: glMaterialfv(GL_FRONT, GL_SPECULAR, 0x43c06b70 -> { 1, 1, 1, 1
})
trace.call: glMaterialfv(GL_FRONT, GL_DIFFUSE, 0x43c06b80 -> { 0.7, 0.7, 0.7,
1 })
trace.call: glColorMaterial(GL_FRONT_AND_BACK, GL_AMBIENT_AND_DIFFUSE)
trace.call: glEnable(GL_COLOR_MATERIAL)
trace.call: glDisable(GL_TEXTURE_2D)
trace.call: glDisable(GL_TEXTURE_1D)
trace.call: glPushMatrix()
trace.call: glLoadIdentity()
trace.call: glBegin(GL_LINES)
trace.call: glColor3f(1, 0, 0)
trace.call: glVertex3fv(0x43c06b30 -> { 0, 0, 0 })
trace.call: glVertex3fv(0x43c06b60 -> { 3.28, 0, 0 })
trace.call: glColor3f(0, 1, 0)
trace.call: glVertex3fv(0x43c06b30 -> { 0, 0, 0 })
.....
I tried calling getNextClient with GL_TRUE (block)...but it had no effect.
So my question is how to make sure that the stream has been deserialized
into GL calls before I can continue making GL calls?
-Dan
|
|
From: Brian P. <bri...@tu...> - 2006-09-22 14:45:19
|
Daniel E. Shipton wrote: > Are gluPerspective, gluOrtho calls sent over the wire? Is there a way > to catch them? No. > I see that gluPerspective is called in the atlantis test program but > does not show up in the print spu log file but it seems as though it is > being transmitted because the view is correct. Any advice on how to > "catch" this call? I tried to add it to the printspu but it doesn't > seem to catch it and I wonder if I need to be doing something different > to catch a glu call instead of a gl... All the glu calls are converted into gl calls by the libGLU.so library. -Brian |
|
From: Daniel E. S. <dan...@gm...> - 2006-09-22 14:40:36
|
Are gluPerspective, gluOrtho calls sent over the wire? Is there a way to catch them? I see that gluPerspective is called in the atlantis test program but does not show up in the print spu log file but it seems as though it is being transmitted because the view is correct. Any advice on how to "catch" this call? I tried to add it to the printspu but it doesn't seem to catch it and I wonder if I need to be doing something different to catch a glu call instead of a gl... Thanks. -Dan |
|
From: Joseph P. <j-...@no...> - 2006-09-21 22:39:06
|
Same problem. Is there a way to disable using CGL? Since the X11 server/utils that OSX come with include GLX, it might work if i can avoid CGL all together. Open to any suggestions at this point ;-) --Joe On Sep 21, 2006, at 5:03 PM, Brian Paul wrote: > Try copying over the include/GL/glext.h file from Cr 1.9 to 1.8. > > -Brian > > Joseph Paris wrote: >> I can't get Cr 1.8 to build on OSX. Some GL_MAP2_VERTEX_ATTRIB >> undeclared build errors in pack_map.c It lists the whole lot of em. >> >> --Joe >> >> >> On Sep 21, 2006, at 3:49 PM, Brian Paul wrote: >> >> >>> Does Cr 1.8 work for you on OS X? >>> >>> If so, try diff'ing the files under opengl_stub/ and spu_loader/ to >>> see what might have changed between 1.8 and 1.9. >>> >>> -Brian >> >> >> >> --------------------------------------------------------------------- >> ---- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to >> share your >> opinions on IT & business topics through brief surveys -- and earn >> cash >> http://www.techsay.com/default.php? >> page=join.php&p=sourceforge&CID=DEVDEV >> _______________________________________________ >> Chromium-users mailing list >> Chr...@li... >> https://lists.sourceforge.net/lists/listinfo/chromium-users >> > > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys -- and earn > cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Chromium-users mailing list > Chr...@li... > https://lists.sourceforge.net/lists/listinfo/chromium-users |
|
From: Brian P. <bri...@tu...> - 2006-09-21 22:03:56
|
Try copying over the include/GL/glext.h file from Cr 1.9 to 1.8. -Brian Joseph Paris wrote: > I can't get Cr 1.8 to build on OSX. Some GL_MAP2_VERTEX_ATTRIB > undeclared build errors in pack_map.c It lists the whole lot of em. > > --Joe > > > On Sep 21, 2006, at 3:49 PM, Brian Paul wrote: > > >>Does Cr 1.8 work for you on OS X? >> >>If so, try diff'ing the files under opengl_stub/ and spu_loader/ to >>see what might have changed between 1.8 and 1.9. >> >>-Brian > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Chromium-users mailing list > Chr...@li... > https://lists.sourceforge.net/lists/listinfo/chromium-users > |
|
From: Joseph P. <j-...@no...> - 2006-09-21 21:57:59
|
I can't get Cr 1.8 to build on OSX. Some GL_MAP2_VERTEX_ATTRIB undeclared build errors in pack_map.c It lists the whole lot of em. --Joe On Sep 21, 2006, at 3:49 PM, Brian Paul wrote: > > Does Cr 1.8 work for you on OS X? > > If so, try diff'ing the files under opengl_stub/ and spu_loader/ to > see what might have changed between 1.8 and 1.9. > > -Brian |
9 messages has been excluded from this view by a project administrator.
