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

[Chromium-dev] Re: [Chromium-users] CR aborts in glNewList, glTexImage1D or glGet.

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

Volz, Bill (WRVO) (Bill.Volz) wrote:
> I have an app that aborts when I turn on certain objects to show. I 
> noticed that this is occuring inside of a NewList with 
> GL_COMPILE_AND_EXECUTE and that may be unstable. There are no glGet* 
> calls that I can find, unless it was the one that caused it all to 
> crash. The part of the log follows. I can send the entire log if 
> requested, it's about 200K compressed.
> 
> Any ideas on how this can be fixed? Is it possible to fix? I don't have 
> access to the code for the program, so this needs to be fixed in CR. The 
> configuration file is the latest autodmx.conf with a print SPU added.
> 
> System: 6 dual AMD Opteron, 8 GB ram, FX3000G with 6111 driver, 
> displaying to 12 LCD's, each at 1280 x 1024 into a mural of 3 rows of 4 
> LCD's.

It's really hard to know that the problem is, or how to fix it, 
without a test program.  The same applies to the feedback and array 
SPU problems you reported.  The .conf files really don't provide any 
insight.

I personally don't have the spare time to write test programs to try 
to reproduce any of these.  If you could provide small/simple tests to 
reproduce the problems, that would make things _much_ easier.

-Brian

Re: [Chromium-dev] JOGL and Chromium

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

This is concerning:

Using ATI workaround of dispatching display() on event thread
Using ATI workaround of dispatching display() on event thread

So, something in the OGL code or in Java is mucking with the display 
setup.  My guess is that they are doing something odd here that is 
removing chromium from the mix.

-Mike

Ricky Uy wrote:

> Thanks. I converted the program to an EXE using Excelsior Jet. The 
> binary works fine and as expected. However, when I try to run it 
> through Chromium, I get the same results, ie a completely white 
> viewport and then the application hangs. Also, the cr render windows 
> never popup, just the native window, so it's the native window that is 
> white.
>  
> Another thing I noticed is that the application, when run standalone, 
> outputs the following (this is the gears demo by Brian Paul, btw, 
> which two guys seem to have converted into Java):
>  
> CANVAS GL IS: net.java.games.jogl.impl.windows.WindowsGLImpl
> CANVAS GLU IS: net.java.games.jogl.impl.GLUImpl
> Using ATI workaround of dispatching display() on event thread
> Using ATI workaround of dispatching display() on event thread
> INIT GL IS: net.java.games.jogl.impl.windows.WindowsGLImpl
> GL_VENDOR: ATI Technologies Inc.
> GL_RENDERER: RADEON 9700 PRO x86/SSE2
> GL_VERSION: 1.5.4454 Win2000 Release
>  
> however, when I run it through Chromium, it only gets this far:
>  
> CANVAS GL IS: net.java.games.jogl.impl.windows.WindowsGLImpl
> CANVAS GLU IS: net.java.games.jogl.impl.GLUImpl
>  
> before it hangs and shows the native window with white viewport. Does 
> anyone have any clues? Brian, have you tried this out before?
>  
> Thanks,
> Ricky
>
> */ta...@su.../* wrote:
>
>     Ricky,
>
>     why not compile the Java program as an executable (should be a
>     couple of
>     freeware to do that). Theoretically this should get round the
>     issue of
>     finding the executable plus if memory serves me right you can add the
>     libraries in the executable binary.
>
>     Regards,
>     Anthony
>
>     --On 20 October 2004 09:33 -0700 Ricky Uy wrote:
>
>     >
>     > Hi All,
>     >
>     > I am trying to run some Java OpenGL programs through Chromium
>     using the
>     > JOGL binding, but I'm running into two main issues. The first is
>     that
>     > I've compiled the programs and exported them as JAR files.
>     Crappfaker
>     > can't find jar files on the path...and it can't find batch scripts
>     > either. Do I really have to write a C program that just calls a
>     script
>     > that launches the JAR file, and would that even work?
>     >
>     > Seco! ndly, I've tried to bypass all of this by just putting the
>     > crfaker.dll in the JRE/bin folder and renaming it to
>     opengl32.dll (ie, I
>     > put it in the same folder as jogl.dll). But when I double-click
>     to try to
>     > run the application, the window that opens up is just white, and the
>     > application hangs. It does this even if I've already started the
>     > mothership and a crserver using crdemo.conf.
>     >
>     > This is all being done on a Windows machine with an ATI Radeon
>     9700 Pro
>     > card. Could someone please help me on this? Thanks so much.
>     >
>     > Ricky
>     >
>     >
>     >
>     >
>     > __________________________________________________
>     > Do you Yahoo!?
>     > vote.yahoo.com - Register online to vote today!
>
>
>
>
>
>
>     -------------------------------------------------------
>     This SF.net email is sponsored by: IT Product Guide on
>     ITManagersJournal
>     Use IT products in your business? Tell us what you think of! them.
>     Give us
>     Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find
>     out more
>     http://productguide.itmanagersjournal.com/guidepromo.tmpl
>     _______________________________________________
>     Chromium-dev mailing list
>     Chr...@li...
>     https://lists.sourceforge.net/lists/listinfo/chromium-dev
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>

Re: [Chromium-dev] JOGL and Chromium

[Ricky Uy <ric...@ya...>]

Thanks. I converted the program to an EXE using Excelsior Jet. The binary works fine and as expected. However, when I try to run it through Chromium, I get the same results, ie a completely white viewport and then the application hangs. Also, the cr render windows never popup, just the native window, so it's the native window that is white. 
 
Another thing I noticed is that the application, when run standalone, outputs the following (this is the gears demo by Brian Paul, btw, which two guys seem to have converted into Java):
 
CANVAS GL IS: net.java.games.jogl.impl.windows.WindowsGLImpl
CANVAS GLU IS: net.java.games.jogl.impl.GLUImpl
Using ATI workaround of dispatching display() on event thread
Using ATI workaround of dispatching display() on event thread
INIT GL IS: net.java.games.jogl.impl.windows.WindowsGLImpl
GL_VENDOR: ATI Technologies Inc.
GL_RENDERER: RADEON 9700 PRO x86/SSE2
GL_VERSION: 1.5.4454 Win2000 Release
 
however, when I run it through Chromium, it only gets this far:
 
CANVAS GL IS: net.java.games.jogl.impl.windows.WindowsGLImpl
CANVAS GLU IS: net.java.games.jogl.impl.GLUImpl
 
before it hangs and shows the native window with white viewport. Does anyone have any clues? Brian, have you tried this out before?
 
Thanks,
Ricky

ta...@su... wrote:
Ricky,

why not compile the Java program as an executable (should be a couple of 
freeware to do that). Theoretically this should get round the issue of 
finding the executable plus if memory serves me right you can add the 
libraries in the executable binary.

Regards,
Anthony

--On 20 October 2004 09:33 -0700 Ricky Uy wrote:

>
> Hi All,
>
> I am trying to run some Java OpenGL programs through Chromium using the
> JOGL binding, but I'm running into two main issues. The first is that
> I've compiled the programs and exported them as JAR files. Crappfaker
> can't find jar files on the path...and it can't find batch scripts
> either. Do I really have to write a C program that just calls a script
> that launches the JAR file, and would that even work?
>
> Secondly, I've tried to bypass all of this by just putting the
> crfaker.dll in the JRE/bin folder and renaming it to opengl32.dll (ie, I
> put it in the same folder as jogl.dll). But when I double-click to try to
> run the application, the window that opens up is just white, and the
> application hangs. It does this even if I've already started the
> mothership and a crserver using crdemo.conf.
>
> This is all being done on a Windows machine with an ATI Radeon 9700 Pro
> card. Could someone please help me on this? Thanks so much.
>
> Ricky
>
>
>
>
> __________________________________________________
> Do you Yahoo!?
> vote.yahoo.com - Register online to vote today!






-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Chromium-dev mailing list
Chr...@li...
https://lists.sourceforge.net/lists/listinfo/chromium-dev

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [Chromium-dev] JOGL and Chromium

[<ta...@su...>]

Ricky,

why not compile the Java program as an executable (should be a couple of 
freeware to do that). Theoretically this should get round the issue of 
finding the executable plus if memory serves me right you can add the 
libraries in the executable binary.

Regards,
Anthony

--On 20 October 2004 09:33 -0700 Ricky Uy <ric...@ya...> wrote:

>
> Hi All,
>
> I am trying to run some Java OpenGL programs through Chromium using the
> JOGL binding, but I'm running into two main issues. The first is that
> I've compiled the programs and exported them as JAR files. Crappfaker
> can't find jar files on the path...and it can't find batch scripts
> either. Do I really have to write a C program that just calls a script
> that launches the JAR file, and would that even work?
>
> Secondly, I've tried to bypass all of this by just putting the
> crfaker.dll in the JRE/bin folder and renaming it to opengl32.dll (ie, I
> put it in the same folder as jogl.dll). But when I double-click to try to
> run the application, the window that opens up is just white, and the
> application hangs. It does this even if I've already started the
> mothership and a crserver using crdemo.conf.
>
> This is all being done on a Windows machine with an ATI Radeon 9700 Pro
> card. Could someone please help me on this? Thanks so much.
>
> Ricky
>
>
>
>
> __________________________________________________
> Do you Yahoo!?
> vote.yahoo.com - Register online to vote today!

[Chromium-dev] JOGL and Chromium

[Ricky Uy <ric...@ya...>]

Hi All,

I am trying to run some Java OpenGL programs through Chromium using the JOGL binding, but I'm running into two main issues. The first is that I've compiled the programs and exported them as JAR files. Crappfaker can't find jar files on the path...and it can't find batch scripts either. Do I really have to write a C program that just calls a script that launches the JAR file, and would that even work?

Secondly, I've tried to bypass all of this by just putting the crfaker.dll in the JRE/bin folder and renaming it to opengl32.dll (ie, I put it in the same folder as jogl.dll). But when I double-click to try to run the application, the window that opens up is just white, and the application hangs. It does this even if I've already started the mothership and a crserver using crdemo.conf.

This is all being done on a Windows machine with an ATI Radeon 9700 Pro card. Could someone please help me on this? Thanks so much.

Ricky

 

		
---------------------------------
Do you Yahoo!?
vote.yahoo.com - Register online to vote today!

Re: [Chromium-dev] OpenGL-ES

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

James Amendolagine wrote:
> On Tue, 2004-10-12 at 11:16, James Amendolagine wrote:
> 
>>On Tue, 2004-10-12 at 09:03, James Amendolagine wrote:
>>
>>>On Tue, 2004-10-12 at 08:26, Brian Paul wrote:
>>
>>>>What kind of Chromium configuration did you test with?
>>>>
>>>
>>>The first one was a client renderer. I'm currently going through and
>>>testing some client - server configurations. 
>>>
>>
>>OK, I think that I see what you may have been getting at. 
>>
>>The client-server tests failed with a link error. 
>>So append these files to the list of modified Chromium files: 
>>
>>packer/pack_swap_texture.c
>>packer/pack_texture.c
>>
> 
> 
> I've run through a simple sanity test of each of ES the calls in a
> client-server mode, and everything seems to work now. 
> 
> A few more files needed to be adjusted: 
> 
>    include/state/cr_statetypes.h
>    packer/pack_currenttypes.py
>    packer/pack_lights.c
>    packer/pack_materials.c
>    packer/pack_matrices.c
>    packer/pack_swap_texture.c
>    packer/pack_texture.c
>    packer/packer.py
>    packer/packer_special
>    spu/tilesort/length_table.py
>    spu/tilesort/pinch_convert.py
>    state_tracker/convert.py
>    state_tracker/state_current.py
>    state_tracker/state_lighting.c
> 
> 
> I've briefly looked through the license, and I'm not sure what the exact
> restrictions on chromium are (as far as it's open-source nature). It's
> not GPL as far as I can tell. 
> 
> I wasn't too worried up front, as I intend to share the source. Still, I
> would like to know, what are the restrictions of the license? They
> appear to be fairly loose, and not require sharing of the source. 

It's a standard BSD license.  See 
http://www.opensource.org/licenses/bsd-license.php

-Brian

Re: [Chromium-dev] OpenGL-ES

[James A. <ja...@it...>]

On Tue, 2004-10-12 at 11:16, James Amendolagine wrote:
> On Tue, 2004-10-12 at 09:03, James Amendolagine wrote:
> > On Tue, 2004-10-12 at 08:26, Brian Paul wrote:
> 
> > > What kind of Chromium configuration did you test with?
> > > 
> > 
> > The first one was a client renderer. I'm currently going through and
> > testing some client - server configurations. 
> > 
> 
> OK, I think that I see what you may have been getting at. 
> 
> The client-server tests failed with a link error. 
> So append these files to the list of modified Chromium files: 
> 
> packer/pack_swap_texture.c
> packer/pack_texture.c
> 

I've run through a simple sanity test of each of ES the calls in a
client-server mode, and everything seems to work now. 

A few more files needed to be adjusted: 

   include/state/cr_statetypes.h
   packer/pack_currenttypes.py
   packer/pack_lights.c
   packer/pack_materials.c
   packer/pack_matrices.c
   packer/pack_swap_texture.c
   packer/pack_texture.c
   packer/packer.py
   packer/packer_special
   spu/tilesort/length_table.py
   spu/tilesort/pinch_convert.py
   state_tracker/convert.py
   state_tracker/state_current.py
   state_tracker/state_lighting.c


I've briefly looked through the license, and I'm not sure what the exact
restrictions on chromium are (as far as it's open-source nature). It's
not GPL as far as I can tell. 

I wasn't too worried up front, as I intend to share the source. Still, I
would like to know, what are the restrictions of the license? They
appear to be fairly loose, and not require sharing of the source. 

In any event, if anyone is interested in the ES port please let me know.

Jamie




> The client-server mode now passes some simple tests. 
> 
> 
> > Jamie
> > 
> > > -Brian
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> > Use IT products in your business? Tell us what you think of them. Give us
> > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> > http://productguide.itmanagersjournal.com/guidepromo.tmpl
> > _______________________________________________
> > Chromium-dev mailing list
> > Chr...@li...
> > https://lists.sourceforge.net/lists/listinfo/chromium-dev
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev

Re: [Chromium-dev] OpenGL-ES

[James A. <ja...@it...>]

On Tue, 2004-10-12 at 09:03, James Amendolagine wrote:
> On Tue, 2004-10-12 at 08:26, Brian Paul wrote:

> > What kind of Chromium configuration did you test with?
> > 
> 
> The first one was a client renderer. I'm currently going through and
> testing some client - server configurations. 
> 

OK, I think that I see what you may have been getting at. 

The client-server tests failed with a link error. 
So append these files to the list of modified Chromium files: 

packer/pack_swap_texture.c
packer/pack_texture.c

The client-server mode now passes some simple tests. 


> Jamie
> 
> > -Brian
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev

Re: [Chromium-dev] OpenGL-ES

[James A. <ja...@it...>]

On Tue, 2004-10-12 at 08:26, Brian Paul wrote:
> I'm really swamped this week and won't have time to look at this in 
> detail for probably a couple of weeks (out of town next week).  A few 
> quick comments below:
> 
> 
> James Amendolagine wrote:
> > On Thu, 2004-09-16 at 13:21, Brian Paul wrote:
> > 
> >>OpenGL-ES also defines an API for pixelformat/drawable/context 
> >>management (like GLX or WGL) called "EGS": 
> >>http://www.khronos.org/cgi-bin/fetch/fetch.cgi?egl_1_1
> >>
> > 
> > 
> > OK, I've done a first pass at an ES version of chromium. 
> > 
> > 
> > I've kept notes on the files that required modification: 
> > -glapi_parser/APIspec.txt  
> > -opengl_stub/defs.py
> > -state_tracker/state_buffer.txt 
> > -state_tracker/state_special
> > -state_tracker/state_attrib.c    
> > -state_tracker/state_buffer.c
> > -state_tracker/state_get.txt
> > -include/state/cr_buffer.h
> > -include/state/cr_attrib.h
> > -state_tracker/state_fog.c
> > -state_tracker/state_get.py
> > -state_tracker/state_lighting.c
> > -state_tracker/state_line.c
> > -state_tracker/state_point.c
> > -state_tracker/state_polygon.c
> > -state_tracker/state_texture.c
> > -state_tracker/state_transform.c
> > -packer/packer.def -- also needs some mod
> > 
> > -glapi_parser/apiutil.py:    // added the type    'GLclampx': 4,
> > -glapi_parser/apiutil.py:    // added the type    'GLfixed': 4,
> > -progs/packer/packertest.py: 'GLfixed':    ('%d','int'),
> > -spu/printspu/printspu.h, printspu_matrices.c ... 
> > -packer/packer_special
> > 
> > -include/cr_estypes.h // added this file
> > 
> > -packer test makefile needed to add an entry for pakerteset600 .. 625
> >    needed to edit packertest.py to handle a GLfixed params and GLfixed 
> > 
> > 
> > 
> > Changes to the APIspec.txt file along the lines of this: 
> > 
> > -----------------------------------------------------------
> > ###############################################
> > #  ESification
> > ###############################################
> > name		Frustumf
> > return		void
> > param		left		GLfloat
> > paramlist	left		-1.0
> > param		right		GLfloat
> > paramlist	right		1.0
> > param		bottom		GLfloat
> > paramlist	bottom		-1.0
> > param		top		GLfloat
> > paramlist	top		1.0
> > param		zNear		GLfloat
> > paramlist	zNear		1.0
> > param		zFar		GLfloat
> > paramlist	zFar		10.0
> > category	1.0
> 
> The category for all these functions should probably be something new, 
> like "ES-1.0".  I think this field is significant in one or two of the 
> Python code generator scripts.
> 
> 

Good, I was thinking that it should be done like this, but hadn't gotten
around to sorting through how to do it. 

> 
> > I've seperated the EGL work from the ES work by adding an ES
> > functionality wrapper to the Mesa- OpenGL library on my system -- So
> > OpenGL on my system now looks like GL + GLES. 
> 
> I think I've heard of a few OpenGL / OpenGL ES wrappers being in 
> existance.  Have you looked at any of those.
> 

The one that I have used in the past wasn't an easy fit for the quick
testing that I was trying to accomplish. -- It forces you to use EGL,
and it does a dlopen on the "real" OpenGL lib, only providing the
symbols for the GLES API (which wrap the apropiate GL calls). 

For my testing, I was mixing GL, and GLES a little, just so I could
quickly build a test and see if the ES calls were working. A pure ES
test would be better... 


This is the wrapper that I was using. 
http://www.khronos.org/opengles/documentation/gles-1.0c.tgz

>From what I can see about EGL, I'm not sure if it will really be the
glut, or SDL that it hoped. It looks like the reality will be that each
embedded platform will have it's own quirky bring-up code. This is one
of the reasons that I have not focused on the EGL side yet. 




> 
> > I did a sanity test on all of the GLES calls now in Chromium by building
> > a test application that does drawing using each ES call. This now works
> > through the chromium system. 
> 
> What kind of Chromium configuration did you test with?
> 

The first one was a client renderer. I'm currently going through and
testing some client - server configurations. 

Jamie

> -Brian

Re: [Chromium-dev] OpenGL-ES

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

I'm really swamped this week and won't have time to look at this in 
detail for probably a couple of weeks (out of town next week).  A few 
quick comments below:


James Amendolagine wrote:
> On Thu, 2004-09-16 at 13:21, Brian Paul wrote:
> 
>>OpenGL-ES also defines an API for pixelformat/drawable/context 
>>management (like GLX or WGL) called "EGS": 
>>http://www.khronos.org/cgi-bin/fetch/fetch.cgi?egl_1_1
>>
> 
> 
> OK, I've done a first pass at an ES version of chromium. 
> 
> 
> I've kept notes on the files that required modification: 
> -glapi_parser/APIspec.txt  
> -opengl_stub/defs.py
> -state_tracker/state_buffer.txt 
> -state_tracker/state_special
> -state_tracker/state_attrib.c    
> -state_tracker/state_buffer.c
> -state_tracker/state_get.txt
> -include/state/cr_buffer.h
> -include/state/cr_attrib.h
> -state_tracker/state_fog.c
> -state_tracker/state_get.py
> -state_tracker/state_lighting.c
> -state_tracker/state_line.c
> -state_tracker/state_point.c
> -state_tracker/state_polygon.c
> -state_tracker/state_texture.c
> -state_tracker/state_transform.c
> -packer/packer.def -- also needs some mod
> 
> -glapi_parser/apiutil.py:    // added the type    'GLclampx': 4,
> -glapi_parser/apiutil.py:    // added the type    'GLfixed': 4,
> -progs/packer/packertest.py: 'GLfixed':    ('%d','int'),
> -spu/printspu/printspu.h, printspu_matrices.c ... 
> -packer/packer_special
> 
> -include/cr_estypes.h // added this file
> 
> -packer test makefile needed to add an entry for pakerteset600 .. 625
>    needed to edit packertest.py to handle a GLfixed params and GLfixed 
> 
> 
> 
> Changes to the APIspec.txt file along the lines of this: 
> 
> -----------------------------------------------------------
> ###############################################
> #  ESification
> ###############################################
> name		Frustumf
> return		void
> param		left		GLfloat
> paramlist	left		-1.0
> param		right		GLfloat
> paramlist	right		1.0
> param		bottom		GLfloat
> paramlist	bottom		-1.0
> param		top		GLfloat
> paramlist	top		1.0
> param		zNear		GLfloat
> paramlist	zNear		1.0
> param		zFar		GLfloat
> paramlist	zFar		10.0
> category	1.0

The category for all these functions should probably be something new, 
like "ES-1.0".  I think this field is significant in one or two of the 
Python code generator scripts.



> I've seperated the EGL work from the ES work by adding an ES
> functionality wrapper to the Mesa- OpenGL library on my system -- So
> OpenGL on my system now looks like GL + GLES. 

I think I've heard of a few OpenGL / OpenGL ES wrappers being in 
existance.  Have you looked at any of those.


> I did a sanity test on all of the GLES calls now in Chromium by building
> a test application that does drawing using each ES call. This now works
> through the chromium system. 

What kind of Chromium configuration did you test with?

-Brian

Re: [Chromium-dev] OpenGL-ES

[James A. <ja...@it...>]

On Mon, 2004-10-11 at 10:14, Mike Houston wrote:
> Based on a REALLY quick pass, this looks good.  The main question is 
> what the end model will be?  Do we want to be able to convert ES to 
> OpenGL and vice versa on the fly, or do we mainly just want to support 
> ES apps/devices?
> 

I think that both will be possible. Currently it's like this: 

ESapp -> Chromium -> renderSPU --> GLES

I believe that it would be pretty straight forward to write a wrapper
render SPU so that this will be possible: 

ESapp -> Chromium -> wrapRenderSPU --> GL

or 

GLapp -> Chromium -> wrapRenderSPU2 -> GLES
 







> -Mike
> 
> James Amendolagine wrote:
> > On Thu, 2004-09-16 at 13:21, Brian Paul wrote:
> > 
> >>OpenGL-ES also defines an API for pixelformat/drawable/context 
> >>management (like GLX or WGL) called "EGS": 
> >>http://www.khronos.org/cgi-bin/fetch/fetch.cgi?egl_1_1
> >>
> > 
> > 
> > OK, I've done a first pass at an ES version of chromium. 
> > 
> > 
> > I've kept notes on the files that required modification: 
> > -glapi_parser/APIspec.txt  
> > -opengl_stub/defs.py
> > -state_tracker/state_buffer.txt 
> > -state_tracker/state_special
> > -state_tracker/state_attrib.c    
> > -state_tracker/state_buffer.c
> > -state_tracker/state_get.txt
> > -include/state/cr_buffer.h
> > -include/state/cr_attrib.h
> > -state_tracker/state_fog.c
> > -state_tracker/state_get.py
> > -state_tracker/state_lighting.c
> > -state_tracker/state_line.c
> > -state_tracker/state_point.c
> > -state_tracker/state_polygon.c
> > -state_tracker/state_texture.c
> > -state_tracker/state_transform.c
> > -packer/packer.def -- also needs some mod
> > 
> > -glapi_parser/apiutil.py:    // added the type    'GLclampx': 4,
> > -glapi_parser/apiutil.py:    // added the type    'GLfixed': 4,
> > -progs/packer/packertest.py: 'GLfixed':    ('%d','int'),
> > -spu/printspu/printspu.h, printspu_matrices.c ... 
> > -packer/packer_special
> > 
> > -include/cr_estypes.h // added this file
> > 
> > -packer test makefile needed to add an entry for pakerteset600 .. 625
> >    needed to edit packertest.py to handle a GLfixed params and GLfixed 
> > 

Re: [Chromium-dev] OpenGL-ES

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

Based on a REALLY quick pass, this looks good.  The main question is 
what the end model will be?  Do we want to be able to convert ES to 
OpenGL and vice versa on the fly, or do we mainly just want to support 
ES apps/devices?

-Mike

James Amendolagine wrote:
> On Thu, 2004-09-16 at 13:21, Brian Paul wrote:
> 
>>OpenGL-ES also defines an API for pixelformat/drawable/context 
>>management (like GLX or WGL) called "EGS": 
>>http://www.khronos.org/cgi-bin/fetch/fetch.cgi?egl_1_1
>>
> 
> 
> OK, I've done a first pass at an ES version of chromium. 
> 
> 
> I've kept notes on the files that required modification: 
> -glapi_parser/APIspec.txt  
> -opengl_stub/defs.py
> -state_tracker/state_buffer.txt 
> -state_tracker/state_special
> -state_tracker/state_attrib.c    
> -state_tracker/state_buffer.c
> -state_tracker/state_get.txt
> -include/state/cr_buffer.h
> -include/state/cr_attrib.h
> -state_tracker/state_fog.c
> -state_tracker/state_get.py
> -state_tracker/state_lighting.c
> -state_tracker/state_line.c
> -state_tracker/state_point.c
> -state_tracker/state_polygon.c
> -state_tracker/state_texture.c
> -state_tracker/state_transform.c
> -packer/packer.def -- also needs some mod
> 
> -glapi_parser/apiutil.py:    // added the type    'GLclampx': 4,
> -glapi_parser/apiutil.py:    // added the type    'GLfixed': 4,
> -progs/packer/packertest.py: 'GLfixed':    ('%d','int'),
> -spu/printspu/printspu.h, printspu_matrices.c ... 
> -packer/packer_special
> 
> -include/cr_estypes.h // added this file
> 
> -packer test makefile needed to add an entry for pakerteset600 .. 625
>    needed to edit packertest.py to handle a GLfixed params and GLfixed 
> 

Re: [Chromium-dev] OpenGL-ES

[James A. <ja...@it...>]

On Thu, 2004-09-16 at 13:21, Brian Paul wrote:
> OpenGL-ES also defines an API for pixelformat/drawable/context 
> management (like GLX or WGL) called "EGS": 
> http://www.khronos.org/cgi-bin/fetch/fetch.cgi?egl_1_1
> 

OK, I've done a first pass at an ES version of chromium. 


I've kept notes on the files that required modification: 
-glapi_parser/APIspec.txt  
-opengl_stub/defs.py
-state_tracker/state_buffer.txt 
-state_tracker/state_special
-state_tracker/state_attrib.c    
-state_tracker/state_buffer.c
-state_tracker/state_get.txt
-include/state/cr_buffer.h
-include/state/cr_attrib.h
-state_tracker/state_fog.c
-state_tracker/state_get.py
-state_tracker/state_lighting.c
-state_tracker/state_line.c
-state_tracker/state_point.c
-state_tracker/state_polygon.c
-state_tracker/state_texture.c
-state_tracker/state_transform.c
-packer/packer.def -- also needs some mod

-glapi_parser/apiutil.py:    // added the type    'GLclampx': 4,
-glapi_parser/apiutil.py:    // added the type    'GLfixed': 4,
-progs/packer/packertest.py: 'GLfixed':    ('%d','int'),
-spu/printspu/printspu.h, printspu_matrices.c ... 
-packer/packer_special

-include/cr_estypes.h // added this file

-packer test makefile needed to add an entry for pakerteset600 .. 625
   needed to edit packertest.py to handle a GLfixed params and GLfixed 



Changes to the APIspec.txt file along the lines of this: 

-----------------------------------------------------------
###############################################
#  ESification
###############################################
name		Frustumf
return		void
param		left		GLfloat
paramlist	left		-1.0
param		right		GLfloat
paramlist	right		1.0
param		bottom		GLfloat
paramlist	bottom		-1.0
param		top		GLfloat
paramlist	top		1.0
param		zNear		GLfloat
paramlist	zNear		1.0
param		zFar		GLfloat
paramlist	zFar		10.0
category	1.0
chromium	extpack

name		Frustumx
return		void
param		left		GLfixed
paramlist	left		-1.0
param		right		GLfixed
paramlist	right		1.0
param		bottom		GLfixed
paramlist	bottom		-1.0
param		top		GLfixed
paramlist	top		1.0
param		zNear		GLfixed
paramlist	zNear		1.0
param		zFar		GLfixed
paramlist	zFar		10.0
category	1.0
chromium	extpack

name		Fogx
return		void
param		pname		GLenum
param		param		GLfixed
paramprop	pname		GL_FOG_DENSITY GL_FOG_START GL_FOG_END GL_FOG_INDEX 
category	1.0
chromium	extpack

name		Fogxv
return		void
param		pname		GLenum
paramprop	pname		GL_FOG_MODE GL_FOG_DENSITY GL_FOG_START GL_FOG_END
GL_FOG_INDEX GL_FOG_COLOR
param		params		const GLfixed *
paramvec	params		GL_LINEAR
category	1.0
chromium	extpack

name		DepthRangef
return		void
param		zNear		GLclampf
param		zFar		GLclampf
category	1.0
chromium	extpack

name		DepthRangex
return		void
param		zNear		GLclampx
param		zFar		GLclampx
category	1.0
chromium	extpack

name		Color4x
return		void
param		red		GLfixed
param		green		GLfixed
param		blue		GLfixed
param		alpha		GLfixed
category	1.0
props		pervertex
chromium	extpack

name		ClearDepthx
return		void
param		depth		GLclampx
category	1.0
chromium	extpack

name		ClearDepthf
return		void
param		depth		GLclampd
category	1.0
chromium	extpack

name		AlphaFuncx
return		void
param		func		GLenum
paramprop	func		GL_NEVER GL_LESS GL_EQUAL GL_LEQUAL GL_GREATER
GL_NOTEQUAL GL_GEQUAL GL_ALWAYS
param		ref		GLclampx
category	1.0
chromium	extpack

name		ClearColorx
return		void
param		red		GLclampx
param		green		GLclampx
param		blue		GLclampx
param		alpha		GLclampx
category	1.0
chromium	extpack

name		Lightx
return		void
param		light		GLenum
paramprop	light		GL_LIGHT0 GL_LIGHT1 GL_LIGHT2 GL_LIGHT3 GL_LIGHT4
GL_LIGHT5 GL_LIGHT6 GL_LIGHT7
param		pname		GLenum
paramprop	pname		GL_SPOT_EXPONENT GL_SPOT_CUTOFF GL_CONSTANT_ATTENUATION
GL_LINEAR_ATTENUATION GL_QUADRATIC_ATTENUATION
param		param		GLfixed
paramlist	param		0.0
category	1.0
chromium	extpack

name		Lightxv
return		void
param		light		GLenum
paramprop	light		GL_LIGHT0 GL_LIGHT1 GL_LIGHT2 GL_LIGHT3 GL_LIGHT4
GL_LIGHT5 GL_LIGHT6 GL_LIGHT7
param		pname		GLenum
paramprop	pname		GL_SPOT_EXPONENT GL_SPOT_CUTOFF GL_CONSTANT_ATTENUATION
GL_LINEAR_ATTENUATION GL_QUADRATIC_ATTENUATION
param		param		const GLfixed *
paramlist	param		0.0
category	1.0
chromium	extpack

name		LineWidthx
return		void
param		width		GLfixed
category	1.0
chromium	extpack

name		LoadMatrixx
return		void
param		m		const GLfixed *
paramvec	m		1 0 0 0 0 1 0 0 0 0 0 1 0 0 0 1
vector		m		16
category	1.0
chromium	extpack

name		MultMatrixx
return		void
param		m		const GLfixed *
paramvec	m		1 0 0 0 0 1 0 0 0 0 0 1 0 0 0 1
vector		m		16
category	1.0
chromium	extpack

name		Translatex
return		void
param		x		GLfixed
param		y		GLfixed
param		z		GLfixed
category	1.0
chromium	extpack

name		Rotatex
return		void
param		angle		GLfixed
param		x		GLfixed
param		y		GLfixed
param		z		GLfixed
category	1.0
chromium	extpack

name		Scalex
return		void
param		x		GLfixed
param		y		GLfixed
param		z		GLfixed
category	1.0
chromium	extpack

name		Orthox
return		void
param		left		GLfixed
param		right		GLfixed
param		bottom		GLfixed
param		top		GLfixed
param		zNear		GLfixed
param		zFar		GLfixed
category	1.0
chromium	extpack

name		Orthof
return		void
param		left		GLfloat
param		right		GLfloat
param		bottom		GLfloat
param		top		GLfloat
param		zNear		GLfloat
param		zFar		GLfloat
category	1.0
chromium	extpack

name		PointSizex
return		void
param		size		GLfixed
category	1.0
chromium	extpack

name		PolygonOffsetx
return		void
param		factor		GLfixed
param		units		GLfixed
category	1.1
chromium	extpack

name		Materialx
return		void
param		face		GLenum
paramprop	face		GL_FRONT GL_BACK GL_FRONT_AND_BACK
param		pname		GLenum
paramprop	pname		GL_SHININESS
param		param		GLfixed
paramlist	param		1.0
category	1.0
chromium	extpack

name		Materialxv
return		void
param		face		GLenum
paramprop	face		GL_FRONT GL_BACK GL_FRONT_AND_BACK
param		pname		GLenum
paramprop	pname		GL_AMBIENT GL_DIFFUSE GL_SPECULAR GL_EMISSION
GL_SHININESS GL_AMBIENT_AND_DIFFUSE GL_COLOR_INDEXES
param		params		const GLfixed *
paramvec	params		0.8 0.8 0.5 0.1
category	1.0
chromium	extpack

name		Normal3x
return		void
param		nx		GLfixed
param		ny		GLfixed
param		nz		GLfixed
category	1.0
props		pervertex
chromium	extpack

name		SampleCoveragex
return		void
param		value		GLclampx
param		invert		GLboolean
category	1.0
chromium	extpack

name		TexEnvx
return		void
param		target		GLenum
param		pname		GLenum
paramset	[ target pname ] [ GL_TEXTURE_ENV ] [ GL_TEXTURE_ENV_MODE ]
paramset	[ target pname ] [ GL_POINT_SPRITE_ARB ] [ GL_COORD_REPLACE_ARB
]
paramset	[ target pname ] [ GL_COMBINE_RGB_EXT ] [ GL_DOT3_RGB_EXT
GL_DOT3_RGBA_EXT ]
paramset	[ target pname ] [ GL_TEXTURE_FILTER_CONTROL_EXT ] [
GL_TEXTURE_LOD_BIAS_EXT ]
param		param		GLfixed
paramlist	param		GL_MODULATE GL_DECAL GL_BLEND GL_REPLACE GL_ADD 
category	1.0
chromium	nopack

name		TexEnvxv
return		void
param		target		GLenum
param		pname		GLenum
paramset	[ target pname ] [ GL_TEXTURE_ENV ] [ GL_TEXTURE_ENV_MODE ]
paramset	[ target pname ] [ GL_POINT_SPRITE_ARB ] [ GL_COORD_REPLACE_ARB
]
paramset	[ target pname ] [ GL_COMBINE_RGB_EXT ] [ GL_DOT3_RGB_EXT
GL_DOT3_RGBA_EXT ]
paramset	[ target pname ] [ GL_TEXTURE_FILTER_CONTROL_EXT ] [
GL_TEXTURE_LOD_BIAS_EXT ]
param		params		const GLfixed *
paramvec	params		0.0 0.0 0.0 0.0
category	1.0
chromium	extpack
vectoralias	TexEnvx

name		TexParameterx
return		void
param		target		GLenum
param		pname		GLenum
param		param		GLfixed
paramset	[ target pname param ]	[ GL_TEXTURE_1D GL_TEXTURE_2D
GL_TEXTURE_3D ] [ GL_TEXTURE_MIN_FILTER ] [ GL_NEAREST GL_LINEAR
GL_NEAREST_MIPMAP_NEAREST GL_LINEAR_MIPMAP_NEAREST
GL_NEAREST_MIPMAP_LINEAR GL_LINEAR_MIPMAP_LINEAR ]
paramset	[ target pname param ]	[ GL_TEXTURE_1D GL_TEXTURE_2D
GL_TEXTURE_3D ] [ GL_TEXTURE_MAG_FILTER ] [ GL_NEAREST GL_LINEAR ]
paramset	[ target pname param ]	[ GL_TEXTURE_1D GL_TEXTURE_2D
GL_TEXTURE_3D ] [ GL_TEXTURE_COMPARE_MODE_ARB ] [
GL_COMPARE_R_TO_TEXTURE_ARB ]
paramset	[ target pname param ]	[ GL_TEXTURE_1D GL_TEXTURE_2D
GL_TEXTURE_3D ] [ GL_TEXTURE_WRAP_S GL_TEXTURE_WRAP_T GL_TEXTURE_WRAP_R
] [ GL_CLAMP GL_CLAMP_TO_EDGE GL_REPEAT GL_CLAMP_TO_BORDER_ARB
GL_MIRRORED_REPEAT_ARB ]
paramset	[ target pname param ]	[ GL_TEXTURE_1D GL_TEXTURE_2D
GL_TEXTURE_3D ] [ GL_GENERATE_MIPMAP_SGIS ] [ GL_TRUE GL_FALSE ]
paramset	[ target pname param ]	[ GL_TEXTURE_1D GL_TEXTURE_2D
GL_TEXTURE_3D ] [ GL_DEPTH_TEXTURE_MODE_ARB ] [ GL_ALPHA GL_LUMINANCE
GL_INTENSITY ]
category	1.0
chromium	nopack

name		MultiTexCoord4x
return		void
param		texture		GLenum
paramprop	texture		GL_TEXTURE0 GL_TEXTURE1 GL_TEXTURE2 GL_TEXTURE3
GL_TEXTURE4 GL_TEXTURE5 GL_TEXTURE6 GL_TEXTURE7
param		s		GLfixed
param		t		GLfixed
param		r		GLfixed
param		q		GLfixed
category	1.0

name		TexParameterxv
return		void
param		target		GLenum
paramprop	target		GL_TEXTURE_1D GL_TEXTURE_2D GL_TEXTURE_3D
param		pname		GLenum
paramprop	pname		GL_TEXTURE_MIN_FILTER GL_TEXTURE_MAG_FILTER
GL_TEXTURE_MIN_LOD GL_TEXTURE_MAX_LOD GL_TEXTURE_BASE_LEVEL
GL_TEXTURE_MAX_LEVEL GL_TEXTURE_WRAP_S GL_TEXTURE_WRAP_T
GL_TEXTURE_WRAP_R GL_TEXTURE_PRIORITY GL_TEXTURE_COMPARE_FUNC_ARB
GL_TEXTURE_COMPARE_MODE_ARB
param		params		const GLfixed *
category	1.0
chromium	extpack
vectoralias	TexParameterx

###############################################
#  ESification
###############################################



I've seperated the EGL work from the ES work by adding an ES
functionality wrapper to the Mesa- OpenGL library on my system -- So
OpenGL on my system now looks like GL + GLES. 

I did a sanity test on all of the GLES calls now in Chromium by building
a test application that does drawing using each ES call. This now works
through the chromium system. 




> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev

[Chromium-dev] Distributed work on chromium

[Ely L. <ely...@cs...>]

Hey,
As part of my university work I wanted to do something related to
distributed rendering.
Looking around the net I found chromium to be a very intresting project.
I'm doing the work for Prof. Amnon Barak which is known for www.mosix.org.
Which is a way to do clustering with support of things like migrating
processess between computers.
Anyhow since I'm sort of new to the field I wonder if anyone might have an
idea on where I might be of use. I'm especially intrested in things
related to schedualing, and ways to use mosix's special features to make
rendering more efficiant.

Ely Levy
System group
Hebrew University
Jerusalem Israel

Re: [Chromium-dev] Re: [Chromium-users] Nvidia 3000G Support

[Jamison D. <da...@cs...>]

Yes, the trapezoids are spinning and they appear to be framelocked.

Jamison

Katharine Chartrand wrote:
> Are the white trapezoids spinning?
> 
>  >KNC<
> 
> At 09:38 AM 10/7/2004 -0400, you wrote:
> 
>> Hi,
>>
>> I see the two white trapezoids also when I run this code on our 3000G 
>> opteron cluster.  However, the frames appear to be synchronized.  I 
>> ran swaplock -f 300 and swaplock -f 1000 on two seperate nodes.  The 
>> buffer swaps appear to be completely in sync.
>>
>> I tested this on both the x86_64 6106 drivers and the x86_64 6111 
>> drivers.
>>
>> Jamison Daniel
>> Oak Ridge National Laboratory,
>> d5...@or...
>>
>>
>> On Wed, 6 Oct 2004, Chartrand Katharine N. wrote:
>>
>>> They aren't really animating.  What I see is two white trapazoids not
>>> doing anything.  What should I see?
>>>
>>>> KNC<
>>>
>>>
>>> On Wed, 6 Oct 2004, Brian Paul wrote:
>>>
>>>>
>>>> Not necessarily.  The true test is looking at the screens and
>>>> observing if they're animating/updating in lock step.
>>>>
>>>> -Brian
>>>>
>>>> Chartrand Katharine N. wrote:
>>>>
>>>>> Brian,
>>>>>
>>>>> If I get the following in both terminals does that mean it worked?
>>>>>
>>>>> glXQueryMaxSwapGroupsNV: maxGroups=1 maxBarriers=1
>>>>> glXJoinSwapGroupNV worked!
>>>>> glXBindSwapBarrierNV worked!
>>>>>
>>>>>
>>>>>> KNC<
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, 23 Sep 2004, Brian Paul wrote:
>>>>>
>>>>>
>>>>>> Chartrand Katharine N. wrote:
>>>>>>
>>>>>>> I am running nvidia 3000gs with the 6591 driver and linux 2.4.26 
>>>>>>> and I
>>>>>>> am not sure I have a swaplock or framelock problem.
>>>>>>
>>>>>>
>>>>>> Unless you explicitly set the proper Render SPU options for 
>>>>>> framelock,
>>>>>> you're not using that facility.  And since I was never able to get 
>>>>>> the
>>>>>> framelock feature to work here, I'm not sure the Render SPU code 
>>>>>> is up
>>>>>> to snuff.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Everything
>>>>>>> seems to be in sync unless I have a very large data set in a 
>>>>>>> particular
>>>>>>> application (not running over chromium).  With this application, 
>>>>>>> an image
>>>>>>> on our multipanel display will be six inches out of alignment 
>>>>>>> between
>>>>>>> panels as we translate it quickly.
>>>>>>
>>>>>>
>>>>>> That sounds like ordinary network/Chromium latency.
>>>>>> The tilesort SPU sends geometry in round-robin order to the 
>>>>>> servers so
>>>>>> there is some latency in the updates from one server to the next.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> My hunch, however, was that the
>>>>>>> problem was with
>>>>>>> the application, not the cards because we see the same behavior 
>>>>>>> with our
>>>>>>> wildcats cards.
>>>>>>
>>>>>>
>>>>>> Probably Chromium, not the application.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> This 6591 driver was given to us by nvidia to stop a combination of
>>>>>>> problems: stereo flickering and chromium apps crashing, and it 
>>>>>>> seems to
>>>>>>> have fixed them both.  I don't believe it is a released driver, 
>>>>>>> but I will
>>>>>>> ask our nvidia contact if I can distribute it.  My questions are:
>>>>>>>
>>>>>>> 1. can I have a copy of your test program so I can see if I have 
>>>>>>> this
>>>>>>> framelock problem (and don't know it!) with this 6591 driver.
>>>>>>
>>>>>>
>>>>>> Attached.  I've sent it to so many people I figured everyone had 
>>>>>> it by
>>>>>> now. :)
>>>>>>
>>>>>>
>>>>>>
>>>>>>> 2. what are the exact symptoms of this type of framelock, swaplock
>>>>>>> problem. For example, would stereo work at all with this 
>>>>>>> framelock problem
>>>>>>> you describe.  Would you just get a flicker in the stereo?
>>>>>>
>>>>>>
>>>>>> Stereo would probably "work" but the left/right synchronization among
>>>>>> all the screens wouldn't occur.  It would confuse your eyes and maybe
>>>>>> give you a headache after a while.
>>>>>>
>>>>>> -Brian
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -------------------------------------------------------
>>>>> This SF.net email is sponsored by: IT Product Guide on 
>>>>> ITManagersJournal
>>>>> Use IT products in your business? Tell us what you think of them. 
>>>>> Give us
>>>>> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find 
>>>>> out more
>>>>> http://productguide.itmanagersjournal.com/guidepromo.tmpl
>>>>> _______________________________________________
>>>>> Chromium-users mailing list
>>>>> Chr...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/chromium-users
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
>>> Use IT products in your business? Tell us what you think of them. 
>>> Give us
>>> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find 
>>> out more
>>> http://productguide.itmanagersjournal.com/guidepromo.tmpl
>>> _______________________________________________
>>> Chromium-users mailing list
>>> Chr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/chromium-users
>>
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
>> Use IT products in your business? Tell us what you think of them. Give us
>> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out 
>> more
>> http://productguide.itmanagersjournal.com/guidepromo.tmpl
>> _______________________________________________
>> Chromium-users mailing list
>> Chr...@li...
>> https://lists.sourceforge.net/lists/listinfo/chromium-users
> 
> 
> 

Re: [Chromium-dev] Re: [Chromium-users] Nvidia 3000G Support

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

Chartrand Katharine N. wrote:
> They aren't really animating.  What I see is two white trapazoids not 
> doing anything.  What should I see?

The should be rotating at the same rate.

-Brian

Re: [Chromium-dev] Re: [Chromium-users] Nvidia 3000G Support

[Jamison R. D. <da...@cs...>]

Hi,

I see the two white trapazoids also when I run this code on our 3000G 
opteron cluster.  However, the frames appear to be synchronized.  I ran 
swaplock -f 300 and swaplock -f 1000 on two seperate nodes.  The buffer 
swaps appear to be completely in sync.

I tested this on both the x86_64 6106 drivers and the x86_64 6111 drivers.

Jamison Daniel
Oak Ridge National Laboratory,
d5...@or...


On Wed, 6 Oct 2004, 
Chartrand Katharine N. wrote:

> They aren't really animating.  What I see is two white trapazoids not
> doing anything.  What should I see?
>
>> KNC<
>
> On Wed, 6 Oct 2004, Brian Paul wrote:
>
>>
>> Not necessarily.  The true test is looking at the screens and
>> observing if they're animating/updating in lock step.
>>
>> -Brian
>>
>> Chartrand Katharine N. wrote:
>>> Brian,
>>>
>>> If I get the following in both terminals does that mean it worked?
>>>
>>> glXQueryMaxSwapGroupsNV: maxGroups=1 maxBarriers=1
>>> glXJoinSwapGroupNV worked!
>>> glXBindSwapBarrierNV worked!
>>>
>>>
>>>> KNC<
>>>
>>>
>>>
>>> On Thu, 23 Sep 2004, Brian Paul wrote:
>>>
>>>
>>>> Chartrand Katharine N. wrote:
>>>>
>>>>> I am running nvidia 3000gs with the 6591 driver and linux 2.4.26 and I
>>>>> am not sure I have a swaplock or framelock problem.
>>>>
>>>> Unless you explicitly set the proper Render SPU options for framelock,
>>>> you're not using that facility.  And since I was never able to get the
>>>> framelock feature to work here, I'm not sure the Render SPU code is up
>>>> to snuff.
>>>>
>>>>
>>>>
>>>>> Everything
>>>>> seems to be in sync unless I have a very large data set in a particular
>>>>> application (not running over chromium).  With this application, an image
>>>>> on our multipanel display will be six inches out of alignment between
>>>>> panels as we translate it quickly.
>>>>
>>>> That sounds like ordinary network/Chromium latency.
>>>> The tilesort SPU sends geometry in round-robin order to the servers so
>>>> there is some latency in the updates from one server to the next.
>>>>
>>>>
>>>>
>>>>> My hunch, however, was that the
>>>>> problem was with
>>>>> the application, not the cards because we see the same behavior with our
>>>>> wildcats cards.
>>>>
>>>> Probably Chromium, not the application.
>>>>
>>>>
>>>>
>>>>> This 6591 driver was given to us by nvidia to stop a combination of
>>>>> problems: stereo flickering and chromium apps crashing, and it seems to
>>>>> have fixed them both.  I don't believe it is a released driver, but I will
>>>>> ask our nvidia contact if I can distribute it.  My questions are:
>>>>>
>>>>> 1. can I have a copy of your test program so I can see if I have this
>>>>> framelock problem (and don't know it!) with this 6591 driver.
>>>>
>>>> Attached.  I've sent it to so many people I figured everyone had it by
>>>> now. :)
>>>>
>>>>
>>>>
>>>>> 2. what are the exact symptoms of this type of framelock, swaplock
>>>>> problem. For example, would stereo work at all with this framelock problem
>>>>> you describe.  Would you just get a flicker in the stereo?
>>>>
>>>> Stereo would probably "work" but the left/right synchronization among
>>>> all the screens wouldn't occur.  It would confuse your eyes and maybe
>>>> give you a headache after a while.
>>>>
>>>> -Brian
>>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
>>> Use IT products in your business? Tell us what you think of them. Give us
>>> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
>>> http://productguide.itmanagersjournal.com/guidepromo.tmpl
>>> _______________________________________________
>>> Chromium-users mailing list
>>> Chr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/chromium-users
>>>
>>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Chromium-users mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-users
>

Re: [Chromium-dev] Re: [Chromium-users] Nvidia 3000G Support

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

Not necessarily.  The true test is looking at the screens and 
observing if they're animating/updating in lock step.

-Brian

Chartrand Katharine N. wrote:
> Brian,
> 
> If I get the following in both terminals does that mean it worked?
> 
> glXQueryMaxSwapGroupsNV: maxGroups=1 maxBarriers=1
> glXJoinSwapGroupNV worked!
> glXBindSwapBarrierNV worked!
> 
> 
>>KNC<
> 
>  
> 
> On Thu, 23 Sep 2004, Brian Paul wrote:
> 
> 
>>Chartrand Katharine N. wrote:
>>
>>>I am running nvidia 3000gs with the 6591 driver and linux 2.4.26 and I 
>>>am not sure I have a swaplock or framelock problem.
>>
>>Unless you explicitly set the proper Render SPU options for framelock, 
>>you're not using that facility.  And since I was never able to get the 
>>framelock feature to work here, I'm not sure the Render SPU code is up 
>>to snuff.
>>
>>
>>
>>>Everything 
>>>seems to be in sync unless I have a very large data set in a particular 
>>>application (not running over chromium).  With this application, an image 
>>>on our multipanel display will be six inches out of alignment between 
>>>panels as we translate it quickly.
>>
>>That sounds like ordinary network/Chromium latency.
>>The tilesort SPU sends geometry in round-robin order to the servers so 
>>there is some latency in the updates from one server to the next.
>>
>>
>>
>>> My hunch, however, was that the 
>>>problem was with  
>>>the application, not the cards because we see the same behavior with our 
>>>wildcats cards.  
>>
>>Probably Chromium, not the application.
>>
>>
>>
>>>This 6591 driver was given to us by nvidia to stop a combination of 
>>>problems: stereo flickering and chromium apps crashing, and it seems to 
>>>have fixed them both.  I don't believe it is a released driver, but I will 
>>>ask our nvidia contact if I can distribute it.  My questions are:
>>>
>>>1. can I have a copy of your test program so I can see if I have this 
>>>framelock problem (and don't know it!) with this 6591 driver.
>>
>>Attached.  I've sent it to so many people I figured everyone had it by 
>>now. :)
>>
>>
>>
>>>2. what are the exact symptoms of this type of framelock, swaplock 
>>>problem. For example, would stereo work at all with this framelock problem 
>>>you describe.  Would you just get a flicker in the stereo? 
>>
>>Stereo would probably "work" but the left/right synchronization among 
>>all the screens wouldn't occur.  It would confuse your eyes and maybe 
>>give you a headache after a while.
>>
>>-Brian
>>
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Chromium-users mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-users
> 

Re: [Chromium-dev] Chromium on Darwin

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

Darwin builds fine now, but it's still not fully there yet.  There are 
still a few issues with the windows in the tilesort and render SPUs, 
for instance.

I've been testing chromium on a G5 cluster myself, with no big issues.  
I've been mainly testing with sort-first (spheres) and sort-last 
(psubmit_crut) configurations, both of which work pretty well.

  -Chris

On Oct 1, 2004, at 4:49 PM, J.R. Manes wrote:

>
> One thing I haven't been clear on with Chromium is if it works under 
> the Mac OS X yet or not.  It sounds like a few of you all are working 
> on the code...so how far off would you say a Darwin version is?  Or is 
> there one now?
>
> I have a G5 cluster that I'd like to install chromium on...so just 
> wondering what the darwin/chromium status is.
>
> Thanks,
> J.R.
>
> -----
> University of Alaska Fairbanks
> 907-388-5229
> jr...@jr...
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on 
> ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give 
> us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out 
> more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev
>

Re: [Chromium-dev] Darwin's different GL naming scheme - configure?

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

Yup, and I just committed it.  Couldn't do it forcefully, so I worked 
around that.  Now Darwin builds from source without any extra setup. :)

  -Chris

On Oct 1, 2004, at 4:46 PM, Brian Paul wrote:

> Christopher Waters wrote:
>> Due to the way Apple has OpenGL organized, all of the GL header files 
>> are in different locations than on other platforms (GL/ -> OpenGL/ 
>> and GLUT/)
>> Up until now, I've been using symbolic links to point the compiler to 
>> the right gl header files, but I'm trying to get around that.  As of 
>> right now, my best thought is to go through and encase all of the 
>> includes with something like this:
>>     #ifdef DARWIN
>>     #include <OpenGL/gl.h>
>>     #include <GLUT/glut.h>
>>     #else
>>     #include <GL/gl.h>
>>     #include <GL/glut.h>
>>     #endif
>> What would be the best (portable) method of doing this without having 
>> to add these to every single file that needs it? (cr/progs/ 
>> especially)
>> I'm thinking a configure script would help for this, as well as other 
>> things, but I haven't seen any mention of one for chromium..
>
> Ick.  Every GLUT program I've seen uses #include <GL/glut.h>.  If that 
> doesn't work on Darwin, someone screwed up there.
>
> Perhaps a work-around for Chromium would be to make symlinks to 
> Darwin's gl.h, glut.h, etc in Chromium's cr/include/GL directory.
>
> That way, #include <GL/gl.h> and <GL/glut.h> could be satisfied by 
> Chromium's include/GL directory.
>
> Could the symlinks be automatically made during Chromium's build 
> process?
>
> -Brian

[Chromium-dev] Chromium on Darwin

[J.R. M. <jr...@jr...>]

One thing I haven't been clear on with Chromium is if it works under 
the Mac OS X yet or not.  It sounds like a few of you all are working 
on the code...so how far off would you say a Darwin version is?  Or is 
there one now?

I have a G5 cluster that I'd like to install chromium on...so just 
wondering what the darwin/chromium status is.

Thanks,
J.R.

-----
University of Alaska Fairbanks
907-388-5229
jr...@jr...

Re: [Chromium-dev] Darwin's different GL naming scheme - configure?

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

Christopher Waters wrote:
> Due to the way Apple has OpenGL organized, all of the GL header files 
> are in different locations than on other platforms (GL/ -> OpenGL/ and 
> GLUT/)
> 
> Up until now, I've been using symbolic links to point the compiler to 
> the right gl header files, but I'm trying to get around that.  As of 
> right now, my best thought is to go through and encase all of the 
> includes with something like this:
>     #ifdef DARWIN
>     #include <OpenGL/gl.h>
>     #include <GLUT/glut.h>
>     #else
>     #include <GL/gl.h>
>     #include <GL/glut.h>
>     #endif
> 
> What would be the best (portable) method of doing this without having to 
> add these to every single file that needs it? (cr/progs/ especially)
> I'm thinking a configure script would help for this, as well as other 
> things, but I haven't seen any mention of one for chromium..

Ick.  Every GLUT program I've seen uses #include <GL/glut.h>.  If that 
doesn't work on Darwin, someone screwed up there.

Perhaps a work-around for Chromium would be to make symlinks to 
Darwin's gl.h, glut.h, etc in Chromium's cr/include/GL directory.

That way, #include <GL/gl.h> and <GL/glut.h> could be satisfied by 
Chromium's include/GL directory.

Could the symlinks be automatically made during Chromium's build process?

-Brian

[Chromium-dev] Darwin's different GL naming scheme - configure?

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

Due to the way Apple has OpenGL organized, all of the GL header files 
are in different locations than on other platforms (GL/ -> OpenGL/ and 
GLUT/)

Up until now, I've been using symbolic links to point the compiler to 
the right gl header files, but I'm trying to get around that.  As of 
right now, my best thought is to go through and encase all of the 
includes with something like this:
     #ifdef DARWIN
     #include <OpenGL/gl.h>
     #include <GLUT/glut.h>
     #else
     #include <GL/gl.h>
     #include <GL/glut.h>
     #endif

What would be the best (portable) method of doing this without having 
to add these to every single file that needs it? (cr/progs/ especially)
I'm thinking a configure script would help for this, as well as other 
things, but I haven't seen any mention of one for chromium..

  -Chris

[Chromium-dev] Two (probably unrelated) problems with FileClients

[Jeremy W. S. <jw...@cs...>]

Using the config script at the end of the email, under cr-1.6 I am able to
play back OpenGL traces I have made from various applications.  Under 1.7
I get the following output:

CR Debug(alpina:22242): calling crNetConnectToServer( "localhost", 10000,
8096, 0 )
CR Debug(alpina:22242): Connecting to server alpina on port 10000, with
protocol tcpip
CR Debug(alpina:22242): Calling crTCPIPInit()
CR Debug(alpina:22242): Initializing TCPIP

CR Debug(alpina:22242): Calling crTCPIPConnection
CR Debug(alpina:22242): Done calling crTCPIPConnection
CR Debug(alpina:22242): Done connecting to server.
CR Debug(alpina:22242): SPU 1/1: (0) "render"
CR Debug(alpina:22242): crNetSetRank:  set my_rank to 0
CR Debug(alpina:22242): initializing dispatch table 0x811e4d0 (for SPU
error)
CR Debug(alpina:22242): Done initializing the dispatch table for SPU
error, calling the self function
CR Debug(alpina:22242): Done with the self function
CR Debug(alpina:22242): Networking already initialized!
CR Warning(alpina:22242): Couldn't find the CRMOTHERSHIP environment
variable, defaulting to localhost
CR Debug(alpina:22242): calling crNetConnectToServer( "localhost", 10000,
8096, 0 )
CR Debug(alpina:22242): Connecting to server alpina on port 10000, with
protocol tcpip
CR Debug(alpina:22242): Calling crTCPIPInit()
CR Debug(alpina:22242): Calling crTCPIPConnection
CR Debug(alpina:22242): Done calling crTCPIPConnection
CR Debug(alpina:22242): Done connecting to server.
CR Debug(alpina:22242): Looking for the system's OpenGL library...
CR Debug(alpina:22242): Found it in default path.
CR Debug(alpina:22242): Render SPU: Creating default window (visBits=0x1,
id=0)
CR Debug(alpina:22242): Render SPU: Looks like we have GLX
CR Debug(alpina:22242): Render SPU: Chose visual id=0x2c: RGBA=(8,8,8,0)
Z=0 stencil=0 double=0 stereo=0 accum=(16,16,16,16)
CR Debug(alpina:22242): Render SPU: Creating window (visBits=0x1, id=0)
CR Debug(alpina:22242): Render SPU: Created window on display :0.0,
Xvisual 0x2c
CR Debug(alpina:22242): Render SPU: actual window x, y, width, height:
100, 100, 1024, 768
CR Debug(alpina:22242): WindowCreate returned 0
CR Debug(alpina:22242): Render SPU: Created DIRECT context on display
:0.0, Xvisual 0x2c
CR Debug(alpina:22242): Render SPU: GL_VENDOR:   NVIDIA Corporation
CR Debug(alpina:22242): Render SPU: GL_RENDERER: GeForce FX 5200
Ultra/AGP/3DNOW!
CR Debug(alpina:22242): Render SPU: GL_VERSION:  1.5.1 NVIDIA 61.11
CR Debug(alpina:22242): initializing dispatch table 0x811c528 (for SPU
render)
CR Debug(alpina:22242): Done initializing the dispatch table for SPU
render, calling the self function
CR Debug(alpina:22242): Done with the self function
CR Debug(alpina:22242): No tiling information for server!
CR Warning(alpina:22242): It looks like there are nothing but file
clients.  That suits me just fine.
CR Error(alpina:22242): Assertion failed: mural->numExtents > 0, file
server_tiles.c, line 530

Which terminates with SIGTERM, and here's the backtrace:

#0  0x40277ac1 in kill () from /lib/libc.so.6
#1  0x4038f9ed in pthread_kill () from /lib/libpthread.so.0
#2  0x4038fd0b in raise () from /lib/libpthread.so.0
#3  0x402776fa in raise () from /lib/libc.so.6
#4  0x401319a5 in crError (
    format=0x80b4fe0 "Assertion failed: %s, file %s, line %d") at
error.c:158
#5  0x080571bd in crServerGetTileInfoFromMothership (conn=0x811b7e0,
    mural=0x80c5560) at server_tiles.c:530
#6  0x0804b297 in crServerGatherConfiguration (mothership=0x0)
    at server_config.c:397
#7  0x0804a1d4 in CRServerMain (argc=1, argv=0xbffff764) at
server_main.c:170
#8  0x08049e6a in main (argc=1, argv=0xbffff764) at main.c:11
#9  0x40263d06 in __libc_start_main () from /lib/libc.so.6

That's the first problem.  I can't seem to replay any traces under
1.7.  Have others had issues with FileClients under 1.7?

The other problem concerns a particular trace.  Same config file.
cr-1.6.  Here's the output:

CR Warning(alpina:22216): It looks like there are nothing but file
clients.  That suits me just fine.
CR Warning(alpina:22216): Couldn't open X display named '-2147414829'
CR Warning(alpina:22216): Couldn't get a visual,
renderspu_SystemInitVisual failed
CR Warning(alpina:22216): headSpu.CreateContext failed in
crServerDispatchCreateContext()

crserver terminates with SIGSEGV.  Here's the backtrace:

#0  crServerDispatchLoadMatrixf (m=0x417e7478) at server_projmatrix.c:23
#1  0x40123dc3 in crUnpackLoadMatrixf () at unpack_matrices.c:40
#2  0x40120500 in crUnpack (data=0x56, opcodes=0x417e70ab,
num_opcodes=131,
    table=0x417e7050) at unpack.c:1756
#3  0x080549a8 in crServerSerializeRemoteStreams () at server_stream.c:290
#4  0x08049fe8 in CRServerMain (argc=134960048, argv=0x810d408)
    at server_main.c:188
#5  0x08049ea9 in main (argc=1, argv=0xbffff764) at main.c:11
#6  0x4022bd06 in __libc_start_main () from /lib/libc.so.6

crServerDispatchLoadMatrixf tries to access
cr_server.curClient->currentCtx->transform.matrixMode, but
cr_server.curClient->currentCtx is null, as CreateContext failed.

If anybody can provide any input on this I'd be very grateful.  I've been
beating my head against it for a while now.  Also, I'd be happy to supply
traces if they are needed.

Jeremy




# 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) != 2:
        print 'Usage: %s <file>' % sys.argv[0]
        sys.exit(-1)

dump = sys.argv[1]

server_spu = SPU( 'render' )

W = 1024
H = 768

server_spu.Conf( 'window_geometry', [100, 100, W, H] )

server_node = CRNetworkNode( )
server_node.FileClient(dump)

server_node.AddSPU( server_spu )

cr = CR()
cr.AddNode( server_node )
cr.Go()


-- 
Jeremy W. Sheaffer
jw...@cs...
http://cs.virginia.edu/~jws9c/



             /*********************************************
             * The Moving Finger writes; and having writ, *
             *    Moves on: nor all thy piety nor wit     *
             *  Shall lure it back to cancel half a line  *
             *  Nor all thy tears wash out a word of it.  *
             *                                            *
             *                       -Omar Khayyam        *
             *********************************************/

[Chromium-dev] Re: [Chromium-users] CR and DMX not working correctly

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

Volz, Bill (WRVO) (Bill.Volz) wrote:
> Never mind - my problem - it appears that I'm not defining the nodes
> in the correct order in the dmx.conf file.

Please try the autodmx.conf mothership configuration file.  It queries
the DMX server directly, saving you the tedium of defining your node
order, plus removing chances for error.

-Sean

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