Menu
▾
▴
chromium-dev
|
From: James A. <ja...@it...> - 2004-09-16 19:56:03
|
Has anyone done any work to make an ES port? Jamie |
|
From: Mike H. <mho...@gr...> - 2004-09-16 20:10:24
|
What do you mean? ES is just a subset of GL, so the API support is already in Chromium +/- a few special features that may be added along the way for low power devices. The main issue seems to be getting Chromium compiled for the various embedded systems. But, it begs the question, why would you want to run Chromium on embedded GL chips that are not designed to be fast, but low power? -Mike James Amendolagine wrote: > Has anyone done any work to make an ES port? > > Jamie > > > ------------------------------------------------------- > 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 |
|
From: Brian P. <bri...@tu...> - 2004-09-16 20:17:18
|
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 Perhaps Jamie wants to run an app that uses the EGS interface on Chromium. Chromium doesn't support that yet, but it probably wouldn't be too hard to implement. -Brian Mike Houston wrote: > What do you mean? ES is just a subset of GL, so the API support is > already in Chromium +/- a few special features that may be added along > the way for low power devices. The main issue seems to be getting > Chromium compiled for the various embedded systems. > > But, it begs the question, why would you want to run Chromium on > embedded GL chips that are not designed to be fast, but low power? > > -Mike > > James Amendolagine wrote: > >> Has anyone done any work to make an ES port? >> Jamie >> >> >> ------------------------------------------------------- >> 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 > > > > ------------------------------------------------------- > 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 > |
|
From: Jeremy W. S. <jw...@cs...> - 2004-09-20 21:37:46
|
I only just upgraded to 1.7. Now one of my configuration scripts, unchanged from what I used with 1.6, doesn't work. I'm using a file client. crserver terminates with this message: CR Error(alpina:16739): Bad Mothership response: Never heard of faker host alpina. Expected one of: Terminated Notice that the expected hosts list is null. I seem to recall traffic in the recent past about some aspect of the hostname matching having been changed recently? Any suggestions? Jeremy -- 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 * *********************************************/ |
|
From: James A. <ja...@it...> - 2004-10-11 17:05:11
|
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 |
|
From: Brian P. <bri...@tu...> - 2004-10-12 15:25:51
|
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 |
|
From: James A. <ja...@it...> - 2004-10-12 16:04:36
|
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 |
|
From: James A. <ja...@it...> - 2004-10-12 18:17:53
|
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 |
|
From: James A. <ja...@it...> - 2004-10-14 23:30:37
|
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 |
|
From: Brian P. <bri...@tu...> - 2004-10-15 14:45:32
|
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 |
|
From: <ta...@su...> - 2004-09-17 07:37:38
|
Mike, an example of an embedded device using Chromium is provided in a paper from = Lamberti et al "An accelerated remote graphics architecture for PDAs" which = you may find interesting. They used a Chromium cluster and a PDA as the=20 visualisation client using 802.11b for communication. Basically the problem = with integration of Chromium to mobile clients is as you say a compilation=20 issue and getting all the right tools together but a solid OpenGL port is=20 also essential since there aren't that many OpenGL implementations out=20 there for mobile clients. Another issue to consider is the fact that both NVidia and ATI are=20 producing mobile 3D cores which we'll probably see in the market soon=20 enough hence bringing Chromium to mobile platforms can potentially provide=20 advanced graphics features using custom made SPUs that address=20 performance/image quality needs of a mobile client. Usage of Chromium for=20 embedded devices and not just mobile devices (e.g set-top boxes, games=20 consoles) can potentially have quite an impact in the way 3D graphics is=20 addressed for these platforms in my opinion. Regards, Anthony using OpenGL ES for thin clients such as mobile phones and PDAs does have=20 its merits. Lamerti et al. in their paper on --On =D0=DD=EC=F0=F4=E7, 16 =D3=E5=F0=F4=E5=EC=E2=F1=DF=EF=F5 2004 1:10 = =EC=EC -0700 Mike Houston=20 <mho...@gr...> wrote: > What do you mean? ES is just a subset of GL, so the API support is > already in Chromium +/- a few special features that may be added along > the way for low power devices. The main issue seems to be getting > Chromium compiled for the various embedded systems. > > But, it begs the question, why would you want to run Chromium on embedded > GL chips that are not designed to be fast, but low power? > > -Mike > > James Amendolagine wrote: >> Has anyone done any work to make an ES port? >> >> Jamie >> >> >> ------------------------------------------------------- >> 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 > > > ------------------------------------------------------- > 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 |
|
From: Mike H. <mho...@gr...> - 2004-09-17 13:53:15
|
I agree that this usage scenario makes sense. However, sort-last rendering like this doesn't require that many changes to Chromium for ES support. For example, you wouldn't need much besides the glDrawPixels, glWindow, glRasterPos ES versions of those calls and dealing with the EGL stuff. What I was suggesting is that using a cluster of embedded cores might not make sense. However, if high powered chips running OpenGL-ES from say Sony or IBM made their way to market, then I could see the need to have Chromium be able to deal with OpenGL-ES commands. It also might make sense to write a SPU that will translate from GL to OpenGL-ES so that off the shelf apps can be run on such devices. However, as you and I have said, the biggest hurdle to the embedded space will be compilation and code size. I didn't mean to discount the idea, I just wasn't sure what the end goals were. I mean, we've supported other wacky ideas like PS2 and Xbox support... ;-) -Mike ta...@su... wrote: > Mike, > > an example of an embedded device using Chromium is provided in a paper > from Lamberti et al "An accelerated remote graphics architecture for > PDAs" which you may find interesting. They used a Chromium cluster and a > PDA as the visualisation client using 802.11b for communication. > Basically the problem with integration of Chromium to mobile clients is > as you say a compilation issue and getting all the right tools together > but a solid OpenGL port is also essential since there aren't that many > OpenGL implementations out there for mobile clients. > > Another issue to consider is the fact that both NVidia and ATI are > producing mobile 3D cores which we'll probably see in the market soon > enough hence bringing Chromium to mobile platforms can potentially > provide advanced graphics features using custom made SPUs that address > performance/image quality needs of a mobile client. Usage of Chromium > for embedded devices and not just mobile devices (e.g set-top boxes, > games consoles) can potentially have quite an impact in the way 3D > graphics is addressed for these platforms in my opinion. > > Regards, > Anthony > > > using OpenGL ES for thin clients such as mobile phones and PDAs does > have its merits. Lamerti et al. in their paper on > > --On ÐÝìðôç, 16 Óåðôåìâñßïõ 2004 1:10 ìì -0700 Mike Houston > <mho...@gr...> wrote: > >> What do you mean? ES is just a subset of GL, so the API support is >> already in Chromium +/- a few special features that may be added along >> the way for low power devices. The main issue seems to be getting >> Chromium compiled for the various embedded systems. >> >> But, it begs the question, why would you want to run Chromium on embedded >> GL chips that are not designed to be fast, but low power? >> >> -Mike >> >> James Amendolagine wrote: >> >>> Has anyone done any work to make an ES port? >>> >>> Jamie >>> >>> >>> ------------------------------------------------------- >>> 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 >> >> >> >> ------------------------------------------------------- >> 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 > > > > > > > > ------------------------------------------------------- > 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 > |
|
From: James A. <ame...@vi...> - 2004-09-19 17:34:42
|
I believe that I've come full circle on this. I'm going to do my first
try at this as an extension, or an extension-like addition.
Just for some feedback on the documentation, it looks like the extension
addition instructions are out-of-date.
* Update the extension strings in spu/state_tracker/state_limits.c as
well.
* Extensions which add new OpenGL functions are more work. The OpenGL
API dispatcher is defined by the functions in
cr/glapi_parser/system_header/CR_GL.H. New API functions must be
added there.
I could not find spu/state_tracker/state_limits.c
or glapi_parser/system_header/CR_GL.H
Jamie
|
|
From: Brian P. <bri...@tu...> - 2004-09-20 14:35:13
|
James Amendolagine wrote: > I believe that I've come full circle on this. I'm going to do my first > try at this as an extension, or an extension-like addition. > > Just for some feedback on the documentation, it looks like the extension > addition instructions are out-of-date. > > * Update the extension strings in spu/state_tracker/state_limits.c as > well. > * Extensions which add new OpenGL functions are more work. The OpenGL > API dispatcher is defined by the functions in > cr/glapi_parser/system_header/CR_GL.H. New API functions must be > added there. > > > > > I could not find spu/state_tracker/state_limits.c > or glapi_parser/system_header/CR_GL.H I'm updating the docs now. state_limits.c is in the cr/state_tracker/ directory. CR_GL.H no longer exists. New functions are defined in the glapi_parser/APIspec.txt file. -Brian |
|
From: Ricky Uy <ric...@ya...> - 2004-09-21 18:17:09
|
Hi, I remember that a little while ago there was talk that some people were implementing 3000G support in Chromium to handle frame synch using some of the API that is provided by Nvidia with the cards. Has this been completed? If not, what issues are left to resolve? And what kind of support was this exactly? Was this to make sure that the framebuffers in each of the render spu machines had the right frame in it, and that SwapBuffers() calls would be made at about the same time along with an Nvidia call to make sure they refreshed at the same time? I am experiencing some frames getting ahead of others in my wall display and I am interested in pursuing this to fix the problem. The other thing I was thinking might be causing the messed up frame synch is that I have a 25% overlap on each tile, causing the tilesort spu to perform more computations. So yeah, any information on the Nvidia stuff would be greatly appreciated. Thanks so much! Ricky --------------------------------- Do you Yahoo!? vote.yahoo.com - Register online to vote today! |
|
From: Sean A. <sea...@ll...> - 2004-09-21 18:55:14
|
Ricky Uy wrote: > Hi, I remember that a little while ago there was talk that some people > were implementing 3000G support in Chromium to handle frame synch > using some of the API that is provided by Nvidia with the cards. Has > this been completed? If not, what issues are left to resolve? This has yet to be completed. We are working with nVidia to resolve the technical issues, but have yet to reach resolution. Since we haven't been able to fix the problem with test apps, there as of yet no reason to fully integrate the API changes into Chromium or DMX, though there is some support in the render SPU. (see is_swap_master, num_swap_client, nv_swap_clients, nv_swap_group, and swap_master_url) I'm sure Brian has more comments about this. > And what kind of support was this exactly? Was this to make sure that > the framebuffers in each of the render spu machines had the right > frame in it, and that SwapBuffers() calls would be made at about the > same time along with an Nvidia call to make sure they refreshed at the > same time? There are two types of synchronization that one might desire. One is swaplock, where windows are put in to a "swap group". When one window is told to swap, all of them are guaranteed to swap at the same time. This can be accomplished to a large degree in user-space software. In fact, Chromium already support for this in the tilesort SPU (see sync_on_swap, sync_on_finish). In many cases, any tearing that might happen is very minor and isn't even visible to most people. GLXProxy in DMX also has support for this if you pass "-glxsyncswap" to DMX. The second type of synchronization is framelock, where the left and right buffer swaps are synchronized between cards. This type of swap cannot be done in software. It also requires a higher degree of synchronization, as any tearing is easily visible to someone wearing stereo glasses. This is the one that we're having the most trouble with. > I am experiencing some frames getting ahead of others in my wall > display and I am interested in pursuing this to fix the problem. The > other thing I was thinking might be causing the messed up frame synch > is that I have a 25% overlap on each tile, causing the tilesort spu to > perform more computations. So yeah, any information on the Nvidia > stuff would be greatly appreciated. Thanks so much! __ sea...@ll... 925-422-1648 |
|
From: Brian P. <bri...@tu...> - 2004-09-23 15:06:35
|
Sean Ahern wrote: > Ricky Uy wrote: > >>Hi, I remember that a little while ago there was talk that some people >>were implementing 3000G support in Chromium to handle frame synch >>using some of the API that is provided by Nvidia with the cards. Has >>this been completed? If not, what issues are left to resolve? > > > This has yet to be completed. We are working with nVidia to resolve the > technical issues, but have yet to reach resolution. Since we haven't > been able to fix the problem with test apps, there as of yet no reason > to fully integrate the API changes into Chromium or DMX, though there is > some support in the render SPU. (see is_swap_master, num_swap_client, > nv_swap_clients, nv_swap_group, and swap_master_url) > > I'm sure Brian has more comments about this. Not much to add. I haven't heard of anyone having any luck with the 3000G swaplock or framelock feature. NVIDIA and other parties have my test program. Until it works with the test programs, there's no point in trying with Chromium. -Brian |
|
From: Brian P. <bri...@tu...> - 2004-09-23 17:28:43
Attachments:
swaplock.c
|
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 |
|
From: Brian P. <bri...@tu...> - 2004-10-06 22:50:24
|
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 > |
|
From: Jamison R. D. <da...@cs...> - 2004-10-07 13:40:29
|
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 > |
|
From: Brian P. <bri...@tu...> - 2004-10-07 15:24:35
|
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 |
|
From: Jamison D. <da...@cs...> - 2004-10-07 16:18:09
|
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 > > > |
|
From: Mike H. <mho...@gr...> - 2004-09-16 20:12:48
|
To clarify the last message, the OES extensions would need to be added
for 1.1 functional support:
/*****************************************************************************************/
/* OES extension functions
*/
/*****************************************************************************************/
/* OES_matrix_palette */
GLAPI void APIENTRY glCurrentPaletteMatrixOES (GLuint index);
GLAPI void APIENTRY glLoadPaletteFromModelViewMatrixOES (void);
GLAPI void APIENTRY glMatrixIndexPointerOES (GLint size, GLenum type,
GLsizei stride, GLvoid *pointer);
GLAPI void APIENTRY glWeightPointerOES (GLint size, GLenum type, GLsizei
stride, GLvoid *pointer);
/* OES_point_size_array */
GLAPI void APIENTRY glPointSizePointerOES (GLenum type, GLsizei stride,
const GLvoid *pointer);
/* OES_draw_texture */
GLAPI void APIENTRY glDrawTexsOES (GLshort x, GLshort y, GLshort z,
GLshort width, GLshort height);
GLAPI void APIENTRY glDrawTexiOES (GLint x, GLint y, GLint z, GLint
width, GLint height);
GLAPI void APIENTRY glDrawTexfOES (GLfloat x, GLfloat y, GLfloat z,
GLfloat width, GLfloat height);
GLAPI void APIENTRY glDrawTexxOES (GLfixed x, GLfixed y, GLfixed z,
GLfixed width, GLfixed height);
GLAPI void APIENTRY glDrawTexsvOES (GLshort *coords);
GLAPI void APIENTRY glDrawTexivOES (GLint *coords);
GLAPI void APIENTRY glDrawTexfvOES (GLfloat *coords);
GLAPI void APIENTRY glDrawTexxvOES (GLfixed *coords);
-Mike
James Amendolagine wrote:
> Has anyone done any work to make an ES port?
>
> Jamie
>
>
> -------------------------------------------------------
> 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
|
|
From: James A. <ja...@it...> - 2004-09-16 20:36:19
|
On Thu, 2004-09-16 at 13:12, Mike Houston wrote: > To clarify the last message, the OES extensions would need to be added > for 1.1 functional support: > Yes. Plus these (and some fixed point data types): GLAPI void APIENTRY glAlphaFuncx (GLenum func, GLclampx ref); GLAPI void APIENTRY glClearColorx (GLclampx red, GLclampx green, GLclampx blue, GLclampx alpha); GLAPI void APIENTRY glClearDepthf (GLclampf depth); GLAPI void APIENTRY glClearDepthx (GLclampx depth); GLAPI void APIENTRY glColor4x (GLfixed red, GLfixed green, GLfixed blue, GLfixed alpha); GLAPI void APIENTRY glDepthRangef (GLclampf zNear, GLclampf zFar); GLAPI void APIENTRY glDepthRangex (GLclampx zNear, GLclampx zFar); GLAPI void APIENTRY glFogx (GLenum pname, GLfixed param); GLAPI void APIENTRY glFogxv (GLenum pname, const GLfixed *params); GLAPI void APIENTRY glFrustumf (GLfloat left, GLfloat right, GLfloat bottom, GLfloat top, GLfloat zNear, GLfloat zFar); GLAPI void APIENTRY glFrustumx (GLfixed left, GLfixed right, GLfixed bottom, GLfixed top, GLfixed zNear, GLfixed zFar); GLAPI void APIENTRY glLightModelx (GLenum pname, GLfixed param); GLAPI void APIENTRY glLightModelxv (GLenum pname, const GLfixed *params); GLAPI void APIENTRY glLightx (GLenum light, GLenum pname, GLfixed param); GLAPI void APIENTRY glLightxv (GLenum light, GLenum pname, const GLfixed *params); GLAPI void APIENTRY glLineWidthx (GLfixed width); GLAPI void APIENTRY glLoadMatrixx (const GLfixed *m); GLAPI void APIENTRY glMaterialx (GLenum face, GLenum pname, GLfixed param); GLAPI void APIENTRY glMaterialxv (GLenum face, GLenum pname, const GLfixed *params); GLAPI void APIENTRY glMultMatrixf (const GLfloat *m); GLAPI void APIENTRY glMultMatrixx (const GLfixed *m); GLAPI void APIENTRY glMultiTexCoord4x (GLenum target, GLfixed s, GLfixed t, GLfixed r, GLfixed q); GLAPI void APIENTRY glNormal3x (GLfixed nx, GLfixed ny, GLfixed nz); GLAPI void APIENTRY glOrthof (GLfloat left, GLfloat right, GLfloat bottom, GLfloat top, GLfloat zNear, GLfloat zFar); GLAPI void APIENTRY glOrthox (GLfixed left, GLfixed right, GLfixed bottom, GLfixed top, GLfixed zNear, GLfixed zFar); GLAPI void APIENTRY glPointSizex (GLfixed size); GLAPI void APIENTRY glPolygonOffsetx (GLfixed factor, GLfixed units); GLAPI void APIENTRY glRotatex (GLfixed angle, GLfixed x, GLfixed y, GLfixed z); GLAPI void APIENTRY glSampleCoveragex (GLclampx value, GLboolean invert); GLAPI void APIENTRY glScalex (GLfixed x, GLfixed y, GLfixed z); GLAPI void APIENTRY glTexEnvx (GLenum target, GLenum pname, GLfixed param); GLAPI void APIENTRY glTexEnvxv (GLenum target, GLenum pname, const GLfixed *params); GLAPI void APIENTRY glTexParameterx (GLenum target, GLenum pname, GLfixed param); GLAPI void APIENTRY glTranslatex (GLfixed x, GLfixed y, GLfixed z); > /*****************************************************************************************/ > /* OES extension functions > */ > /*****************************************************************************************/ > /* OES_matrix_palette */ > GLAPI void APIENTRY glCurrentPaletteMatrixOES (GLuint index); > GLAPI void APIENTRY glLoadPaletteFromModelViewMatrixOES (void); > GLAPI void APIENTRY glMatrixIndexPointerOES (GLint size, GLenum type, > GLsizei stride, GLvoid *pointer); > GLAPI void APIENTRY glWeightPointerOES (GLint size, GLenum type, GLsizei > stride, GLvoid *pointer); > > /* OES_point_size_array */ > GLAPI void APIENTRY glPointSizePointerOES (GLenum type, GLsizei stride, > const GLvoid *pointer); > > /* OES_draw_texture */ > GLAPI void APIENTRY glDrawTexsOES (GLshort x, GLshort y, GLshort z, > GLshort width, GLshort height); > GLAPI void APIENTRY glDrawTexiOES (GLint x, GLint y, GLint z, GLint > width, GLint height); > GLAPI void APIENTRY glDrawTexfOES (GLfloat x, GLfloat y, GLfloat z, > GLfloat width, GLfloat height); > GLAPI void APIENTRY glDrawTexxOES (GLfixed x, GLfixed y, GLfixed z, > GLfixed width, GLfixed height); > > GLAPI void APIENTRY glDrawTexsvOES (GLshort *coords); > GLAPI void APIENTRY glDrawTexivOES (GLint *coords); > GLAPI void APIENTRY glDrawTexfvOES (GLfloat *coords); > GLAPI void APIENTRY glDrawTexxvOES (GLfixed *coords); > > -Mike > > James Amendolagine wrote: > > > Has anyone done any work to make an ES port? > > > > Jamie > > > > > > ------------------------------------------------------- > > 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 |
|
From: Mike H. <mho...@gr...> - 2004-09-16 20:42:04
|
I don't think anyone is currently working on this, but the extensions should be easy to add if you were so inclined. You can pretty much just replicate the floating point versions and use the new types. The EGS stuff looks to be more tricky... -Mike James Amendolagine wrote: > On Thu, 2004-09-16 at 13:12, Mike Houston wrote: > >>To clarify the last message, the OES extensions would need to be added >>for 1.1 functional support: >> > > > Yes. Plus these (and some fixed point data types): > > > GLAPI void APIENTRY glAlphaFuncx (GLenum func, GLclampx ref); > GLAPI void APIENTRY glClearColorx (GLclampx red, GLclampx green, > GLclampx blue, GLclampx alpha); > GLAPI void APIENTRY glClearDepthf (GLclampf depth); > GLAPI void APIENTRY glClearDepthx (GLclampx depth); > GLAPI void APIENTRY glColor4x (GLfixed red, GLfixed green, GLfixed blue, > GLfixed alpha); > GLAPI void APIENTRY glDepthRangef (GLclampf zNear, GLclampf zFar); > GLAPI void APIENTRY glDepthRangex (GLclampx zNear, GLclampx zFar); > GLAPI void APIENTRY glFogx (GLenum pname, GLfixed param); > GLAPI void APIENTRY glFogxv (GLenum pname, const GLfixed *params); > GLAPI void APIENTRY glFrustumf (GLfloat left, GLfloat right, GLfloat > bottom, GLfloat top, GLfloat zNear, GLfloat zFar); > GLAPI void APIENTRY glFrustumx (GLfixed left, GLfixed right, GLfixed > bottom, GLfixed top, GLfixed zNear, GLfixed zFar); > GLAPI void APIENTRY glLightModelx (GLenum pname, GLfixed param); > GLAPI void APIENTRY glLightModelxv (GLenum pname, const GLfixed > *params); > GLAPI void APIENTRY glLightx (GLenum light, GLenum pname, GLfixed > param); > GLAPI void APIENTRY glLightxv (GLenum light, GLenum pname, const GLfixed > *params); > GLAPI void APIENTRY glLineWidthx (GLfixed width); > GLAPI void APIENTRY glLoadMatrixx (const GLfixed *m); > GLAPI void APIENTRY glMaterialx (GLenum face, GLenum pname, GLfixed > param); > GLAPI void APIENTRY glMaterialxv (GLenum face, GLenum pname, const > GLfixed *params); > GLAPI void APIENTRY glMultMatrixf (const GLfloat *m); > GLAPI void APIENTRY glMultMatrixx (const GLfixed *m); > GLAPI void APIENTRY glMultiTexCoord4x (GLenum target, GLfixed s, GLfixed > t, GLfixed r, GLfixed q); > GLAPI void APIENTRY glNormal3x (GLfixed nx, GLfixed ny, GLfixed nz); > GLAPI void APIENTRY glOrthof (GLfloat left, GLfloat right, GLfloat > bottom, GLfloat top, GLfloat zNear, GLfloat zFar); > GLAPI void APIENTRY glOrthox (GLfixed left, GLfixed right, GLfixed > bottom, GLfixed top, GLfixed zNear, GLfixed zFar); > GLAPI void APIENTRY glPointSizex (GLfixed size); > GLAPI void APIENTRY glPolygonOffsetx (GLfixed factor, GLfixed units); > GLAPI void APIENTRY glRotatex (GLfixed angle, GLfixed x, GLfixed y, > GLfixed z); > GLAPI void APIENTRY glSampleCoveragex (GLclampx value, GLboolean > invert); > GLAPI void APIENTRY glScalex (GLfixed x, GLfixed y, GLfixed z); > GLAPI void APIENTRY glTexEnvx (GLenum target, GLenum pname, GLfixed > param); > GLAPI void APIENTRY glTexEnvxv (GLenum target, GLenum pname, const > GLfixed *params); > GLAPI void APIENTRY glTexParameterx (GLenum target, GLenum pname, > GLfixed param); > GLAPI void APIENTRY glTranslatex (GLfixed x, GLfixed y, GLfixed z); > > > > > > > >>/*****************************************************************************************/ >>/* OES extension functions >> */ >>/*****************************************************************************************/ >>/* OES_matrix_palette */ >>GLAPI void APIENTRY glCurrentPaletteMatrixOES (GLuint index); >>GLAPI void APIENTRY glLoadPaletteFromModelViewMatrixOES (void); >>GLAPI void APIENTRY glMatrixIndexPointerOES (GLint size, GLenum type, >>GLsizei stride, GLvoid *pointer); >>GLAPI void APIENTRY glWeightPointerOES (GLint size, GLenum type, GLsizei >>stride, GLvoid *pointer); >> >>/* OES_point_size_array */ >>GLAPI void APIENTRY glPointSizePointerOES (GLenum type, GLsizei stride, >>const GLvoid *pointer); >> >>/* OES_draw_texture */ >>GLAPI void APIENTRY glDrawTexsOES (GLshort x, GLshort y, GLshort z, >>GLshort width, GLshort height); >>GLAPI void APIENTRY glDrawTexiOES (GLint x, GLint y, GLint z, GLint >>width, GLint height); >>GLAPI void APIENTRY glDrawTexfOES (GLfloat x, GLfloat y, GLfloat z, >>GLfloat width, GLfloat height); >>GLAPI void APIENTRY glDrawTexxOES (GLfixed x, GLfixed y, GLfixed z, >>GLfixed width, GLfixed height); >> >>GLAPI void APIENTRY glDrawTexsvOES (GLshort *coords); >>GLAPI void APIENTRY glDrawTexivOES (GLint *coords); >>GLAPI void APIENTRY glDrawTexfvOES (GLfloat *coords); >>GLAPI void APIENTRY glDrawTexxvOES (GLfixed *coords); >> >>-Mike >> >>James Amendolagine wrote: >> >> >>>Has anyone done any work to make an ES port? >>> >>>Jamie >>> >>> >>>------------------------------------------------------- >>>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 > > > > ------------------------------------------------------- > 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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X