From: Joong Ho \(Johann\) W. <jh...@st...> - 2004-07-26 04:10:46
|
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. - johann. --- import sys sys.path.append( "../server" ) from mothership import * if len(sys.argv) > 1: demo = sys.argv[1] firstExtra = 2 else: demo = "bboxtest" firstExtra = 1 # Collect remaining command line params as program options ExtraOpts = "" for arg in sys.argv[firstExtra:]: ExtraOpts += " " + arg cr = CR() cr.MTU( 10*1024*1024 ) TILE_COLS = 2 TILE_ROWS = 1 TILE_WIDTH = 150 TILE_HEIGHT = 300 clientspuname = 'tilesort' if clientspuname == 'pack' and TILE_ROWS*TILE_COLS != 1: print >> sys.stderr, "You cant use the pack SPU with more than one server." sys.exit(0) tilesortspu = SPU( clientspuname ) #tilesortspu.Conf('preserve_aspect_ratio', 1) tilesortspu.Conf('bucket_mode', 'Uniform Grid') tilesortspu.Conf('draw_bbox', 0) tilesortspu.Conf('bbox_scale', 1.0) tilesortspu.Conf('dlist_state_tracking', 0) readbackspu=SPU('readback') readbackspu.Conf('window_geometry', [ 500, 0, 300, 300 ] ) #readbackspu.Conf('extract_depth', '1') clientnode = CRApplicationNode( ) clientnode.StartDir( crbindir ) clientnode.SetApplication( demo + ExtraOpts) clientnode.AddSPU( readbackspu ) clientnode.AddSPU( tilesortspu ) for row in range(TILE_ROWS): for col in range(TILE_COLS): renderspu = SPU( 'render' ) renderspu.Conf( 'window_geometry', [col*(TILE_WIDTH+10), 1.1*row*TILE_HEIGHT, TILE_WIDTH, TILE_HEIGHT] ) node = CRNetworkNode( ) if clientspuname == 'tilesort': node.AddTile( col*TILE_WIDTH, (TILE_ROWS-row-1)*TILE_HEIGHT, TILE_WIDTH, TILE_HEIGHT ) node.Conf('optimize_bucket', 1) #node.Conf('vertprog_projection_param', 'ModelViewProj') node.AddSPU( renderspu ) cr.AddNode( node ) tilesortspu.AddServer( node, protocol='tcpip', port=7000 + row*TILE_COLS + col ) cr.AddNode( clientnode ) cr.Go() |
From: Brian P. <bri...@tu...> - 2004-07-28 21:54:48
Attachments:
patch
|
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 |
From: Joong Ho \(Johann\) W. <jh...@st...> - 2004-07-29 11:31:26
Attachments:
readback_dmx.conf
|
(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 |
From: Johann W. <jh...@st...> - 2004-08-03 20:47:03
Attachments:
psubmit_bswap.conf
|
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 > > |
From: Mike H. <mho...@gr...> - 2004-08-03 20:53:29
|
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 >> >> > > > |
From: Mike H. <mho...@gr...> - 2004-08-03 20:59:14
|
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 |
From: Brian P. <bri...@tu...> - 2004-08-10 17:30:56
Attachments:
crserverlib.patch
|
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 |