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

RE: [Chromium-dev] Typo in renderspu_wgl.c

[<ma...@co...>]

Archie,

> What kind of error would this produce?

It would cause an error in any implementation of DescribePixelFormat that
checks the reported size of the PIXELFORMATDESCRIPTOR against it's real size.

One case that definitely compares these sizes is in opengl_stub/wgl.c, in the
function wglDescribePixelFormat_prox.

In general, we've been having some issues with Chromium on Windows, but we've
been trying to work through them one at a time... so AFAIK we haven't gotten
to checking out tilesort.

Thanks,
Jon

University of Colorado at Boulder
BP Center for Visualization

[Chromium-dev] cr1.8 and tilesortspu on Windows OS

[<aac...@ad...>]

Hi.

Maybe you are having the same problem that we have been experiencing.  I, also, have had problems using Chromium v1.8 with the tilesort spu.  I did eventually get it to work by removing compiler optimization setting in the "options.mk" file found in the chromium directory.  Change the optimization setting from 1 (compile with optimizations and no debug info) to 0.  I don't know if this is the same problem as you are experiencing, but it is worth a try.

After you change your "options.mk" file setting to 0, do a 'make clean' and a 'make'. 

See if that helps.

Alicia


---- "Jones wrote: 
> Hi,
> 
> What kind of error would this produce?  We're have some trouble with our
> Windows install of Chromium 1.8.  We have it installed on an SGI IRIX
> 6.5, and two Windows XP machines.  On the SGI if we do the 'python
> crdemo.conf atlantis' or 'python crdemo.conf atlantis tilesort' things
> work fine.  On the XP machines if we do 'python crdemo.conf atlantis'
> things work fine, but if we do 'python crdemo.conf atlantis tilesort',
> the GLUT frame and render frame comes up and then Windows pops up and
> says some memory can't be written to.
> 
> Is this a different problem? (hopefully a known one)  Here is the
> crdemo.conf file that was used:
> 
> # 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 = 500
> H = 500
> 
> server_spu.Conf( 'window_geometry', [0, 0, W, H] )
> server_spu.Conf( 'swap_master_url', "" )
> 
> server_node = CRNetworkNode( )
> server_node.AddSPU( server_spu )
> 
> if (clientspuname == 'tilesort' ):
> 	server_node.AddTile( 0, 0, W, H )
> 
> client_node = CRApplicationNode( )
> client_node.AddSPU( client_spu )
> client_spu.AddServer( server_node, 'tcpip' )
> 
> client_node.SetApplication( demo )
> client_node.StartDir( crbindir )
> 
> cr = CR()
> cr.MTU( 1024*1024 )
> cr.AddNode( client_node )
> cr.AddNode( server_node )
> cr.Go()
> 
> 
> 
> Thanks,
> Archie
> 
> 
> 
> 
> 
> -----Original Message-----
> From: chr...@li...
> [mailto:chr...@li...] On Behalf Of Brian
> Paul
> Sent: Wednesday, May 25, 2005 1:15 PM
> To: ma...@co...
> Cc: chr...@li...; ast...@co...;
> gor...@co...
> Subject: Re: [Chromium-dev] Typo in renderspu_wgl.c
> 
> ma...@co... wrote:
> > Hi all,
> > 
> > I think I've spotted a bug in renderspu_wgl.c near line 252 and line
> 270.
> > 
> > The bad code:
> > render_spu.ws.wglDescribePixelFormat( hdc, pixelformat, sizeof(ppfd), 
> > ppfd );
> > 
> > Better code:
> > render_spu.ws.wglDescribePixelFormat( hdc, pixelformat, sizeof(*ppfd),
> 
> > ppfd );
> > 
> > The error near line 270 is similar...
> > 
> > DescribePixelFormat expects the size of the pixelformat structure (~40
> 
> > bytes), not the size of the pointer (4 bytes)!
> 
> I've checked in the change.  Thanks.
> 
> -Brian
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: GoToMeeting - the easiest way to
> collaborate online with coworkers and clients while avoiding the high
> cost of travel and communications. There is no equipment to buy and you
> can meet as often as you want. Try it
> free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate
> online with coworkers and clients while avoiding the high cost of travel and
> communications. There is no equipment to buy and you can meet as often as
> you want. Try it free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev

RE: [Chromium-dev] Typo in renderspu_wgl.c

[Jones, J. A. <jos...@lm...>]

Hi,

What kind of error would this produce?  We're have some trouble with our
Windows install of Chromium 1.8.  We have it installed on an SGI IRIX
6.5, and two Windows XP machines.  On the SGI if we do the 'python
crdemo.conf atlantis' or 'python crdemo.conf atlantis tilesort' things
work fine.  On the XP machines if we do 'python crdemo.conf atlantis'
things work fine, but if we do 'python crdemo.conf atlantis tilesort',
the GLUT frame and render frame comes up and then Windows pops up and
says some memory can't be written to.

Is this a different problem? (hopefully a known one)  Here is the
crdemo.conf file that was used:

# 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 = 500
H = 500

server_spu.Conf( 'window_geometry', [0, 0, W, H] )
server_spu.Conf( 'swap_master_url', "" )

server_node = CRNetworkNode( )
server_node.AddSPU( server_spu )

if (clientspuname == 'tilesort' ):
	server_node.AddTile( 0, 0, W, H )

client_node = CRApplicationNode( )
client_node.AddSPU( client_spu )
client_spu.AddServer( server_node, 'tcpip' )

client_node.SetApplication( demo )
client_node.StartDir( crbindir )

cr = CR()
cr.MTU( 1024*1024 )
cr.AddNode( client_node )
cr.AddNode( server_node )
cr.Go()



Thanks,
Archie





-----Original Message-----
From: chr...@li...
[mailto:chr...@li...] On Behalf Of Brian
Paul
Sent: Wednesday, May 25, 2005 1:15 PM
To: ma...@co...
Cc: chr...@li...; ast...@co...;
gor...@co...
Subject: Re: [Chromium-dev] Typo in renderspu_wgl.c

ma...@co... wrote:
> Hi all,
> 
> I think I've spotted a bug in renderspu_wgl.c near line 252 and line
270.
> 
> The bad code:
> render_spu.ws.wglDescribePixelFormat( hdc, pixelformat, sizeof(ppfd), 
> ppfd );
> 
> Better code:
> render_spu.ws.wglDescribePixelFormat( hdc, pixelformat, sizeof(*ppfd),

> ppfd );
> 
> The error near line 270 is similar...
> 
> DescribePixelFormat expects the size of the pixelformat structure (~40

> bytes), not the size of the pointer (4 bytes)!

I've checked in the change.  Thanks.

-Brian



-------------------------------------------------------
SF.Net email is sponsored by: GoToMeeting - the easiest way to
collaborate online with coworkers and clients while avoiding the high
cost of travel and communications. There is no equipment to buy and you
can meet as often as you want. Try it
free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click
_______________________________________________
Chromium-dev mailing list
Chr...@li...
https://lists.sourceforge.net/lists/listinfo/chromium-dev

Re: [Chromium-dev] Typo in renderspu_wgl.c

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

ma...@co... wrote:
> Hi all,
> 
> I think I've spotted a bug in renderspu_wgl.c near line 252 and line 270.
> 
> The bad code:
> render_spu.ws.wglDescribePixelFormat( hdc, pixelformat, sizeof(ppfd), ppfd );
> 
> Better code:
> render_spu.ws.wglDescribePixelFormat( hdc, pixelformat, sizeof(*ppfd), ppfd );
> 
> The error near line 270 is similar...
> 
> DescribePixelFormat expects the size of the pixelformat structure (~40 bytes),
> not the size of the pointer (4 bytes)!

I've checked in the change.  Thanks.

-Brian

[Chromium-dev] Typo in renderspu_wgl.c

[<ma...@co...>]

Hi all,

I think I've spotted a bug in renderspu_wgl.c near line 252 and line 270.

The bad code:
render_spu.ws.wglDescribePixelFormat( hdc, pixelformat, sizeof(ppfd), ppfd );

Better code:
render_spu.ws.wglDescribePixelFormat( hdc, pixelformat, sizeof(*ppfd), ppfd );

The error near line 270 is similar...

DescribePixelFormat expects the size of the pixelformat structure (~40 bytes),
not the size of the pointer (4 bytes)!


Thanks,
Jon Marbach
University of Colorado

Re: [Chromium-dev] Chromium and ParaView 2.0.1

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

> Joel,
> 
> Could you check out the CVS head code and try ParaView again?  I just 
> fixed a few glReadPixels issues.
> 
> -Brian

Brian, that did the trick!  Thank you very much; we can now run ParaView 2.0.1 
over Chromium.

-Joel

Re: [Chromium-dev] Chromium and ParaView 2.0.1

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

Joel,

Could you check out the CVS head code and try ParaView again?  I just 
fixed a few glReadPixels issues.

-Brian

Re: [Chromium-dev] gets on NOP SPU

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

Oops, I guess I spoke too soon.  The Get routines probably use the 
state tracker simply to avoid returning totally random values to the 
app.  I don't think there's any connection to the crserver since the 
NOP SPU can be used on app nodes too.

-Brian


aac...@ad... wrote:
>>From nop.py, notice it calls 'crState' for 'get' statements and 'nop' for everything else...I was curious about the 'crState'.  Is this some form of state-tracking and how does it work?  See crState in line '2' below.
> 
> nop.py code from the bottom of file
> ...
> 1 elif "get" in apiutil.Properties(func_name):
> 2 	print '\t{ "%s", (SPUGenericFunction) crState%s },' % (func_name, func_name )
> 3 else:
> 4 	print '\t{ "%s", (SPUGenericFunction) nop%s },' % (func_name, func_name )
>  
> 
> 
> 
> ---- Brian Paul <bri...@tu...> wrote: 
> 
>>aac...@ad... wrote:
>>
>>>Hi.
>>>
>>>I had a question about the NOP spu. I noticed that for Extended Opcode
>>>calls which return information all happen to call functions within the
>>>state_tracker\state_regcombiner.c file.
>>
>>The NOP SPU doesn't do anything like that.  See spu/nop/nopspu.c
>>
>>
>>
>>>I assume this is to maintain some sort of state on the crserver
>>>side. Does the application client sit and wait to receive a return
>>>call (crNetSend->crNetRecv) for these Extended Opcode calls, or is it
>>>left waiting forever?
>>>
>>>Does anyone have a good explanation as to what the NOP does when it
>>>receives these Extended Opcodes?
>>
>>Are you sure you're talking about the NOP SPU?
>>
>>-Brian
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by Oracle Space Sweepstakes
>>Want to be the first software developer in space?
>>Enter now for the Oracle Space Sweepstakes!
>>http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
>>_______________________________________________
>>Chromium-dev mailing list
>>Chr...@li...
>>https://lists.sourceforge.net/lists/listinfo/chromium-dev
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev
> 

[Chromium-dev] gets on NOP SPU

[<aac...@ad...>]

From nop.py, notice it calls 'crState' for 'get' statements and 'nop' for everything else...I was curious about the 'crState'.  Is this some form of state-tracking and how does it work?  See crState in line '2' below.

nop.py code from the bottom of file
...
1 elif "get" in apiutil.Properties(func_name):
2 	print '\t{ "%s", (SPUGenericFunction) crState%s },' % (func_name, func_name )
3 else:
4 	print '\t{ "%s", (SPUGenericFunction) nop%s },' % (func_name, func_name )
 



---- Brian Paul <bri...@tu...> wrote: 
> aac...@ad... wrote:
> > Hi.
> > 
> > I had a question about the NOP spu. I noticed that for Extended Opcode
> > calls which return information all happen to call functions within the
> > state_tracker\state_regcombiner.c file.
> 
> The NOP SPU doesn't do anything like that.  See spu/nop/nopspu.c
> 
> 
> > I assume this is to maintain some sort of state on the crserver
> > side. Does the application client sit and wait to receive a return
> > call (crNetSend->crNetRecv) for these Extended Opcode calls, or is it
> > left waiting forever?
> > 
> > Does anyone have a good explanation as to what the NOP does when it
> > receives these Extended Opcodes?
> 
> Are you sure you're talking about the NOP SPU?
> 
> -Brian
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev

Re: [Chromium-dev] NOP SPU

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

aac...@ad... wrote:
> Hi.
> 
> I had a question about the NOP spu. I noticed that for Extended Opcode
> calls which return information all happen to call functions within the
> state_tracker\state_regcombiner.c file.

The NOP SPU doesn't do anything like that.  See spu/nop/nopspu.c


> I assume this is to maintain some sort of state on the crserver
> side. Does the application client sit and wait to receive a return
> call (crNetSend->crNetRecv) for these Extended Opcode calls, or is it
> left waiting forever?
> 
> Does anyone have a good explanation as to what the NOP does when it
> receives these Extended Opcodes?

Are you sure you're talking about the NOP SPU?

-Brian

[Chromium-dev] NOP SPU

[<aac...@ad...>]

Hi.

I had a question about the NOP spu.  I noticed that for Extended Opcode calls which return information all happen to call functions within the state_tracker\state_regcombiner.c file.  

I assume this is to maintain some sort of state on the crserver side.  Does the application client sit and wait to receive a return call (crNetSend->crNetRecv) for these Extended Opcode calls, or is it left waiting forever?  

Does anyone have a good explanation as to what the NOP does when it receives these Extended Opcodes?

Thanks,
Alicia

   

[Chromium-dev] NOP SPU

[<aac...@ad...>]

Hi.

I had a question about the NOP spu.  I noticed that for Extended Opcode calls which return information all happen to call functions within the state_tracker\state_regcombiner.c file.  

I assume this is to maintain some sort of state on the crserver side.  Does the application client sit and wait to receive a return call (crNetSend->crNetRecv) for these Extended Opcode calls, or is it left waiting forever?  

Does anyone have a good explanation as to what the NOP does when it receives these Extended Opcodes?

Thanks,
Alicia

   

[Chromium-dev] Chromium capabilities under Windows OS

[Jones, J. A. <jos...@lm...>]

Hello all, 
I'm working with a group that is trying to develop a large distributed
rendering solution. Our display consists of three tiled projection
displays producing a 30' x 8' Windows desktop. We are able to display
across the three displays using Windows built-in support for multiple
monitors. What I am in dyer need of is some help understanding the
capabilities of Chromium under the Windows OS. For instance, imagine I
have Windows application that has a standard Windows frame, menu, and
toolbar, and some region inside that frame that displays OpenGL
graphics. If I use Chromium, then this application should be faked out
to use Chromium rather than the standard OpenGL library. If this part is
wrong PLEASE correct me.
Here are my main questions: 
1. If there are n machines processing the OpenGL stuff, does Chromium
render the OpenGL scene in the original application frame, or does it
render to a Chromium generated window?
2. Is there a way to control this? Specifically, can we force the
rendering to display in the original Windows application frame? And
preserve the ability to perform tasks such as size and minimize the
application?
Thanks VERY much, 
Archie 

Re: [Chromium-dev] Chromium and ParaView 2.0.1

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

A bit of further info on this: ParaView is calling Chromium with a variety of 
bytes_per_row values and payload lengths, nonzero skipRows and skipPixels, 
various strides equal to bytes_per_row, and alignment=4:

Case 2; payload_len= 146680,bytes_per_row= 760, rows= 193, alignment= 4, 
skipRows= 90, skipPixels= 35, stride= 760
Case 2; payload_len= 156024,bytes_per_row= 788, rows= 198, alignment= 4, 
skipRows= 24, skipPixels= 12, stride= 788
Case 2; payload_len= 265144,bytes_per_row= 1012, rows= 262, alignment= 4, 
skipRows= 24, skipPixels= 0, stride= 1012
(and many more)

The previous version of ParaView (which works with Chromium) does only the 
'doesn't need special packing' case of the if in packspu_neet.c:packspuReadPixe
ls(), except for a few calls to the 'need special packing' clause with much 
simpler parameters:

Case 2; payload_len= 160000,bytes_per_row= 800, rows= 200, alignment= 4, 
skipRows= 0, skipPixels= 0, stride= 800

I'm not sure there is anything to be drawn at that point, in fact, so even 
that call might be broken.

we...@st... said:
> Hey folks;
>   I believe my ReadPixels problem (see below for old email) is arising
> in the  neighborhood of the '#if 0'd code in packspu_net.c:packspuReadP
> ixels().   Brian, your revision 1.16.2.7 of that file file suggests
> that maybe this  routine isn't robust yet, but since I don't
> understand most of the fields of  CRPixelPackState I'm not sure.  The
> new version of ParaView which is causing  the problem has odd-numbered
> x and y origins for the rectangle to be read, so  I'm guessing that
> that might produce an alignment issue.  I have established  that
> execution passes through the 'need special packing' clause of the
> routine.
>   Does anyone know if this clause is trustworthy?

> Thanks, -Joel 

Re: [Chromium-dev] Chromium and ParaView 2.0.1

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

Hey folks;
  I believe my ReadPixels problem (see below for old email) is arising in the 
neighborhood of the '#if 0'd code in packspu_net.c:packspuReadPixels().  
Brian, your revision 1.16.2.7 of that file file suggests that maybe this 
routine isn't robust yet, but since I don't understand most of the fields of 
CRPixelPackState I'm not sure.  The new version of ParaView which is causing 
the problem has odd-numbered x and y origins for the rectangle to be read, so 
I'm guessing that that might produce an alignment issue.  I have established 
that execution passes through the 'need special packing' clause of the routine.
  Does anyone know if this clause is trustworthy?

Thanks,
-Joel

> Joel Welling wrote:
> >>Joel Welling wrote:
> >>
> >>>Hi folks;
> >>>  Is anyone else running ParaView 2.0.1 through Chromium?  I am trying to get 
> >>>this together on our vis cluster, and there are problems with the ReadPixels 
> >>>of the sub-images from the various render servers for compositing (by Ice-T in 
> >>>ParaView) to make the whole image.  The sub-images look like they are being 
> >>>read back at the wrong resolution, such that adjacent pixels in the rendered 
> >>>image are not adjacent in the read-back image.
> >>
> >>Are you running a basic tilesort configuration or is there something 
> >>else going on?
> > 
> > 
> > It's a simpler configuration than that- just a single pack SPU sending to a 
> > render SPU (or a print SPU followed by a render SPU).  Brian, I'll forward the 
> > config file to you under separate mail.  We use it basically to give the 
> > calling application access to a graphics card.
> 
> Hmmm, glReadPixels in the Pack SPU is pretty simple so I doubt the 
> problem is there.
> 
> 
> >>>  I've looked at the images rendered on the individual crservers, and they 
> >>>look just great.  This system did work with earlier versions of ParaView 
> >>>(specifically 1.6.3), so I've compared the OpenGL calls made by the two 
> >>>versions.  The older version reads back images starting at pixel (0,0) and 
> >>>including the entire rendered area, while the new version seems to try to save 
> >>>bytes by only reading back the parts of the image where it thinks stuff has 
> >>>been drawn.  This means that ReadPixels is not done with a corner at (0,0).  
> >>>I'm guessing that perhaps there is a problem with ReadPixels of sections of 
> >>>the rendered image which do not include that corner.
> >>
> >>The tilesort SPU tracks object bounding boxes but that's not used for 
> >>glReadPixels.  So I'm not sure why the coordinates are funny.
> >>
> > 
> > 
> > Note that the coordinate change is apparently due to a change in ParaView, not 
> > to any intervention on Chromium's part.  I think it is this change (between 
> > ParaView 1.something and ParaView 2.0.1) that is messing up our application.
> 
> I guess I'd talk to the ParaView folks at this point if I were you.
> 
> -Brian
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Tell us your software development plans!
> Take this survey and enter to win a one-year sub to SourceForge.net
> Plus IDC's 2005 look-ahead and a copy of this survey
> Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id=105hix
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev

Re: [Chromium-dev] Chromium and ParaView 2.0.1

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

Joel Welling wrote:
>>Joel Welling wrote:
>>
>>>Hi folks;
>>>  Is anyone else running ParaView 2.0.1 through Chromium?  I am trying to get 
>>>this together on our vis cluster, and there are problems with the ReadPixels 
>>>of the sub-images from the various render servers for compositing (by Ice-T in 
>>>ParaView) to make the whole image.  The sub-images look like they are being 
>>>read back at the wrong resolution, such that adjacent pixels in the rendered 
>>>image are not adjacent in the read-back image.
>>
>>Are you running a basic tilesort configuration or is there something 
>>else going on?
> 
> 
> It's a simpler configuration than that- just a single pack SPU sending to a 
> render SPU (or a print SPU followed by a render SPU).  Brian, I'll forward the 
> config file to you under separate mail.  We use it basically to give the 
> calling application access to a graphics card.

Hmmm, glReadPixels in the Pack SPU is pretty simple so I doubt the 
problem is there.


>>>  I've looked at the images rendered on the individual crservers, and they 
>>>look just great.  This system did work with earlier versions of ParaView 
>>>(specifically 1.6.3), so I've compared the OpenGL calls made by the two 
>>>versions.  The older version reads back images starting at pixel (0,0) and 
>>>including the entire rendered area, while the new version seems to try to save 
>>>bytes by only reading back the parts of the image where it thinks stuff has 
>>>been drawn.  This means that ReadPixels is not done with a corner at (0,0).  
>>>I'm guessing that perhaps there is a problem with ReadPixels of sections of 
>>>the rendered image which do not include that corner.
>>
>>The tilesort SPU tracks object bounding boxes but that's not used for 
>>glReadPixels.  So I'm not sure why the coordinates are funny.
>>
> 
> 
> Note that the coordinate change is apparently due to a change in ParaView, not 
> to any intervention on Chromium's part.  I think it is this change (between 
> ParaView 1.something and ParaView 2.0.1) that is messing up our application.

I guess I'd talk to the ParaView folks at this point if I were you.

-Brian

Re: [Chromium-dev] Chromium and ParaView 2.0.1

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

> Joel Welling wrote:
> > Hi folks;
> >   Is anyone else running ParaView 2.0.1 through Chromium?  I am trying to get 
> > this together on our vis cluster, and there are problems with the ReadPixels 
> > of the sub-images from the various render servers for compositing (by Ice-T in 
> > ParaView) to make the whole image.  The sub-images look like they are being 
> > read back at the wrong resolution, such that adjacent pixels in the rendered 
> > image are not adjacent in the read-back image.
> 
> Are you running a basic tilesort configuration or is there something 
> else going on?

It's a simpler configuration than that- just a single pack SPU sending to a 
render SPU (or a print SPU followed by a render SPU).  Brian, I'll forward the 
config file to you under separate mail.  We use it basically to give the 
calling application access to a graphics card.

> 
> 
> >   I've looked at the images rendered on the individual crservers, and they 
> > look just great.  This system did work with earlier versions of ParaView 
> > (specifically 1.6.3), so I've compared the OpenGL calls made by the two 
> > versions.  The older version reads back images starting at pixel (0,0) and 
> > including the entire rendered area, while the new version seems to try to save 
> > bytes by only reading back the parts of the image where it thinks stuff has 
> > been drawn.  This means that ReadPixels is not done with a corner at (0,0).  
> > I'm guessing that perhaps there is a problem with ReadPixels of sections of 
> > the rendered image which do not include that corner.
> 
> The tilesort SPU tracks object bounding boxes but that's not used for 
> glReadPixels.  So I'm not sure why the coordinates are funny.
> 

Note that the coordinate change is apparently due to a change in ParaView, not 
to any intervention on Chromium's part.  I think it is this change (between 
ParaView 1.something and ParaView 2.0.1) that is messing up our application.

-Joel
 
> >   Note that my Chromium is not completely up-to-date from the top of the tree. 
> >  If any corrections have been made to the ReadPixels mechanism since Feb. 21 
> > they might solve my problem.
> 
> I don't think there's been any recent changes in ReadPixels in the 
> tilesort SPU.
> 
> -Brian

Re: [Chromium-dev] Chromium and ParaView 2.0.1

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

Joel Welling wrote:
> Hi folks;
>   Is anyone else running ParaView 2.0.1 through Chromium?  I am trying to get 
> this together on our vis cluster, and there are problems with the ReadPixels 
> of the sub-images from the various render servers for compositing (by Ice-T in 
> ParaView) to make the whole image.  The sub-images look like they are being 
> read back at the wrong resolution, such that adjacent pixels in the rendered 
> image are not adjacent in the read-back image.

Are you running a basic tilesort configuration or is there something 
else going on?


>   I've looked at the images rendered on the individual crservers, and they 
> look just great.  This system did work with earlier versions of ParaView 
> (specifically 1.6.3), so I've compared the OpenGL calls made by the two 
> versions.  The older version reads back images starting at pixel (0,0) and 
> including the entire rendered area, while the new version seems to try to save 
> bytes by only reading back the parts of the image where it thinks stuff has 
> been drawn.  This means that ReadPixels is not done with a corner at (0,0).  
> I'm guessing that perhaps there is a problem with ReadPixels of sections of 
> the rendered image which do not include that corner.

The tilesort SPU tracks object bounding boxes but that's not used for 
glReadPixels.  So I'm not sure why the coordinates are funny.


>   Note that my Chromium is not completely up-to-date from the top of the tree. 
>  If any corrections have been made to the ReadPixels mechanism since Feb. 21 
> they might solve my problem.

I don't think there's been any recent changes in ReadPixels in the 
tilesort SPU.

-Brian

[Chromium-dev] Chromium and ParaView 2.0.1

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

Hi folks;
  Is anyone else running ParaView 2.0.1 through Chromium?  I am trying to get 
this together on our vis cluster, and there are problems with the ReadPixels 
of the sub-images from the various render servers for compositing (by Ice-T in 
ParaView) to make the whole image.  The sub-images look like they are being 
read back at the wrong resolution, such that adjacent pixels in the rendered 
image are not adjacent in the read-back image.
  I've looked at the images rendered on the individual crservers, and they 
look just great.  This system did work with earlier versions of ParaView 
(specifically 1.6.3), so I've compared the OpenGL calls made by the two 
versions.  The older version reads back images starting at pixel (0,0) and 
including the entire rendered area, while the new version seems to try to save 
bytes by only reading back the parts of the image where it thinks stuff has 
been drawn.  This means that ReadPixels is not done with a corner at (0,0).  
I'm guessing that perhaps there is a problem with ReadPixels of sections of 
the rendered image which do not include that corner.
  Note that my Chromium is not completely up-to-date from the top of the tree. 
 If any corrections have been made to the ReadPixels mechanism since Feb. 21 
they might solve my problem.

Thanks,
-Joel

Re: [Chromium-dev] several bugs in pack/unpacking of textures

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

I do apologize for jumping the gun there. At the same time I did that, 
though, I fixed some functions where the packet size was being 
implicitly added to the packed data after calling crPackAlloc, which 
sets that itself, as Greg pointed out.

Looking through what I added to swap_texture, I noticed that most of 
the SWAP functions in pack_swap_texture make calls to crPackFree after 
crHugePacket.  I don't see any significant differences in those 
functions other than swapping the bytes, so perhaps those functions 
should be looked into as well.

  -Chris

On Apr 11, 2005, at 12:07 PM, Greg Humphreys wrote:

> He already checked in the extra calls to crPackFree(), which means
> they are probably being called twice and should be rolled back.  Note
> that this bug will only manifest itself if the texture is larger than
> the pack buffer size, since crPackFree() is a NOP if the packet fits
> in the buffer.
>
> We have to leave the free'ing up to the SPU because some SPU's want to
> keep these pack buffers around for a long time for later analysis or
> playback.  You can't assume that HugePacket() is a fire-and-forget
> model.
>
> On Apr 11, 2005 11:25 AM, Brian Paul <bri...@tu...> 
> wrote:
>>
>> I just did a quick look into this, you should double-check before
>> chaning anything.
>>
>> Anyway, if you call crPackAlloc() you should use crHugePacket() send
>> the message.  crHugePacket() calls the pc->SendHuge() callback.  In
>> the case of the Pack SPU, this is the packspuHuge() function.  The
>> last thing that function does is to call crPackFree() to deallocate
>> the buffer.
>>
>> You might check that the packer functions which call crPackAlloc()
>> also call crHugePacket().
>>
>> -Brian
>>
>>
>> Christopher Waters wrote:
>>> I went through a little more of the packer/unpacker code and tossed 
>>> in a
>>> few more fixes. I also took out one of the "special case" functions,
>>> which seems to probably be the only one that 'needed' to be done at 
>>> all.
>>>
>>> I'm finding some quirks in that crPackFree is not being called in the
>>> functions that use crPackAlloc... shouldn't it always be called?
>>>
>>> -Chris
>>>
>>> Brian Paul wrote:
>>>
>>>> Christopher Waters wrote:
>>>>
>>>>> I just threw together the other 5.  I'm not checking it in myself
>>>>> because I'm only 99% sure it's right, mainly because I've never
>>>>> touched the unpacker before, but it was easy enough.  I also fixed
>>>>> the function that was just added (GLenum was used in all the
>>>>> READ_DATAs, instead of each variable's type)
>>>>
>>>>
>>>>
>>>> The code looks good to me.  I've checked it in.  Thanks!
>>>>
>>>> -Brian
>>>>
>>>>
>>>
>>>
>>> -------------------------------------------------------
>>> SF email is sponsored by - The IT Product Guide
>>> Read honest & candid reviews on hundreds of IT Products from real 
>>> users.
>>> Discover which products truly live up to the hype. Start reading now.
>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>> _______________________________________________
>>> Chromium-dev mailing list
>>> Chr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/chromium-dev
>>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real 
>> users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> _______________________________________________
>> Chromium-dev mailing list
>> Chr...@li...
>> https://lists.sourceforge.net/lists/listinfo/chromium-dev
>>
>>
>
>
> -- 
> Greg Humphreys, Assistant Professor
> Department of Computer Science, University of Virginia
> http://www.cs.virginia.edu/~humper/
>

Re: [Chromium-dev] several bugs in pack/unpacking of textures

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

He already checked in the extra calls to crPackFree(), which means
they are probably being called twice and should be rolled back.  Note
that this bug will only manifest itself if the texture is larger than
the pack buffer size, since crPackFree() is a NOP if the packet fits
in the buffer.

We have to leave the free'ing up to the SPU because some SPU's want to
keep these pack buffers around for a long time for later analysis or
playback.  You can't assume that HugePacket() is a fire-and-forget
model.

On Apr 11, 2005 11:25 AM, Brian Paul <bri...@tu...> wrote:
> 
> I just did a quick look into this, you should double-check before
> chaning anything.
> 
> Anyway, if you call crPackAlloc() you should use crHugePacket() send
> the message.  crHugePacket() calls the pc->SendHuge() callback.  In
> the case of the Pack SPU, this is the packspuHuge() function.  The
> last thing that function does is to call crPackFree() to deallocate
> the buffer.
> 
> You might check that the packer functions which call crPackAlloc()
> also call crHugePacket().
> 
> -Brian
> 
> 
> Christopher Waters wrote:
> > I went through a little more of the packer/unpacker code and tossed in a
> > few more fixes. I also took out one of the "special case" functions,
> > which seems to probably be the only one that 'needed' to be done at all.
> >
> > I'm finding some quirks in that crPackFree is not being called in the
> > functions that use crPackAlloc... shouldn't it always be called?
> >
> > -Chris
> >
> > Brian Paul wrote:
> >
> >> Christopher Waters wrote:
> >>
> >>> I just threw together the other 5.  I'm not checking it in myself
> >>> because I'm only 99% sure it's right, mainly because I've never
> >>> touched the unpacker before, but it was easy enough.  I also fixed
> >>> the function that was just added (GLenum was used in all the
> >>> READ_DATAs, instead of each variable's type)
> >>
> >>
> >>
> >> The code looks good to me.  I've checked it in.  Thanks!
> >>
> >> -Brian
> >>
> >>
> >
> >
> > -------------------------------------------------------
> > SF email is sponsored by - The IT Product Guide
> > Read honest & candid reviews on hundreds of IT Products from real users.
> > Discover which products truly live up to the hype. Start reading now.
> > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> > _______________________________________________
> > Chromium-dev mailing list
> > Chr...@li...
> > https://lists.sourceforge.net/lists/listinfo/chromium-dev
> >
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev
> 
> 


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

Re: [Chromium-dev] several bugs in pack/unpacking of textures

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

I just did a quick look into this, you should double-check before 
chaning anything.

Anyway, if you call crPackAlloc() you should use crHugePacket() send 
the message.  crHugePacket() calls the pc->SendHuge() callback.  In 
the case of the Pack SPU, this is the packspuHuge() function.  The 
last thing that function does is to call crPackFree() to deallocate 
the buffer.

You might check that the packer functions which call crPackAlloc() 
also call crHugePacket().

-Brian



Christopher Waters wrote:
> I went through a little more of the packer/unpacker code and tossed in a 
> few more fixes. I also took out one of the "special case" functions, 
> which seems to probably be the only one that 'needed' to be done at all.
> 
> I'm finding some quirks in that crPackFree is not being called in the 
> functions that use crPackAlloc... shouldn't it always be called?
> 
> -Chris
> 
> Brian Paul wrote:
> 
>> Christopher Waters wrote:
>>
>>> I just threw together the other 5.  I'm not checking it in myself 
>>> because I'm only 99% sure it's right, mainly because I've never 
>>> touched the unpacker before, but it was easy enough.  I also fixed 
>>> the function that was just added (GLenum was used in all the 
>>> READ_DATAs, instead of each variable's type)
>>
>>
>>
>> The code looks good to me.  I've checked it in.  Thanks!
>>
>> -Brian
>>
>>
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev
> 

Re: [Chromium-dev] several bugs in pack/unpacking of textures

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

Well, you only need to call crPackFree if you are concerned about
leaking memory.

On Apr 10, 2005 7:44 AM, Christopher Waters <cr...@ms...> wrote:
> I went through a little more of the packer/unpacker code and tossed in a
> few more fixes. I also took out one of the "special case" functions,
> which seems to probably be the only one that 'needed' to be done at all.
> 
> I'm finding some quirks in that crPackFree is not being called in the
> functions that use crPackAlloc... shouldn't it always be called?
> 
>  -Chris
> 
> Brian Paul wrote:
> 
> > Christopher Waters wrote:
> >
> >> I just threw together the other 5.  I'm not checking it in myself
> >> because I'm only 99% sure it's right, mainly because I've never
> >> touched the unpacker before, but it was easy enough.  I also fixed
> >> the function that was just added (GLenum was used in all the
> >> READ_DATAs, instead of each variable's type)
> >
> >
> > The code looks good to me.  I've checked it in.  Thanks!
> >
> > -Brian
> >
> >
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev
> 
> 


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

Re: [Chromium-dev] several bugs in pack/unpacking of textures

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

I went through a little more of the packer/unpacker code and tossed in a 
few more fixes. I also took out one of the "special case" functions, 
which seems to probably be the only one that 'needed' to be done at all.

I'm finding some quirks in that crPackFree is not being called in the 
functions that use crPackAlloc... shouldn't it always be called?

 -Chris

Brian Paul wrote:

> Christopher Waters wrote:
>
>> I just threw together the other 5.  I'm not checking it in myself 
>> because I'm only 99% sure it's right, mainly because I've never 
>> touched the unpacker before, but it was easy enough.  I also fixed 
>> the function that was just added (GLenum was used in all the 
>> READ_DATAs, instead of each variable's type)
>
>
> The code looks good to me.  I've checked it in.  Thanks!
>
> -Brian
>
>

Re: [Chromium-dev] several bugs in pack/unpacking of textures

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

Christopher Waters wrote:
> I just threw together the other 5.  I'm not checking it in myself 
> because I'm only 99% sure it's right, mainly because I've never touched 
> the unpacker before, but it was easy enough.  I also fixed the function 
> that was just added (GLenum was used in all the READ_DATAs, instead of 
> each variable's type)

The code looks good to me.  I've checked it in.  Thanks!

-Brian