Menu
▾
▴
chromium-dev
|
From: James A. <ja...@it...> - 2004-09-16 22:22:46
|
On Thu, 2004-09-16 at 13:41, Mike Houston wrote: > 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... Actually I believe it's EGL.. > By the way, I've just started working with Chromium (a couple of weeks ago), and I'm very impressed. So if no-one has done this before, I'll just jump in and do it myself. I don't understand the internals well enough yet to have a very useful opinion, but one of my concerns with adding the calls as extensions is will the SPU's still work? ie will the state tracking still be valid? When any of the OpenGL version of these ES calls are made: glClearColorx glClearDepthf glClearDepthx glColor4x glDepthRangef glDepthRangex I imagine that chromium records the state. I guess that I could just replicate the state management that is being done within the associated OpenGL Chromium call. so I add a call glClearColorx, and look at the origional glClearColor, and just replicate most of the function... It looks like this would be done in state_tracker/state_buffer.c > -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 > > > ------------------------------------------------------- > 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-17 01:42:11
|
James Amendolagine wrote:
> On Thu, 2004-09-16 at 13:41, Mike Houston wrote:
>
>>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...
>
> Actually I believe it's EGL..
>
>
> By the way, I've just started working with Chromium (a couple of weeks
> ago), and I'm very impressed.
>
>
> So if no-one has done this before, I'll just jump in and do it myself.
>
>
> I don't understand the internals well enough yet to have a very useful
> opinion, but one of my concerns with adding the calls as extensions is
> will the SPU's still work? ie will the state tracking still be valid?
>
>
> When any of the OpenGL version of these ES calls are made:
> glClearColorx
> glClearDepthf
> glClearDepthx
> glColor4x
> glDepthRangef
> glDepthRangex
>
> I imagine that chromium records the state. I guess that I could just
> replicate the state management that is being done within the associated
> OpenGL Chromium call.
>
> so I add a call glClearColorx, and look at the origional glClearColor,
> and just replicate most of the function...
>
> It looks like this would be done in state_tracker/state_buffer.c
Would it be feasible to simply translate the glFoox functions into the
corresponding conventional OpenGL functions at the dispatch layer?
That is:
void glClearDepthx(GLclampx value)
{
glClearDepth(FixedToDouble(value));
}
That could be implemented in the opengl_stub/* files fairly easily, I
think, without having to touch the rest of the system.
I haven't looked at the ES functions closely enough to know if there's
any potential pitfalls.
-Brian
|
|
From: James A. <ja...@it...> - 2004-09-17 18:19:35
|
On Thu, 2004-09-16 at 18:46, Brian Paul wrote:
> James Amendolagine wrote:
> > On Thu, 2004-09-16 at 13:41, Mike Houston wrote:
> >
> >>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...
> >
> > Actually I believe it's EGL..
> >
> >
> > By the way, I've just started working with Chromium (a couple of weeks
> > ago), and I'm very impressed.
> >
> >
> > So if no-one has done this before, I'll just jump in and do it myself.
> >
> >
> > I don't understand the internals well enough yet to have a very useful
> > opinion, but one of my concerns with adding the calls as extensions is
> > will the SPU's still work? ie will the state tracking still be valid?
> >
> >
> > When any of the OpenGL version of these ES calls are made:
> > glClearColorx
> > glClearDepthf
> > glClearDepthx
> > glColor4x
> > glDepthRangef
> > glDepthRangex
> >
> > I imagine that chromium records the state. I guess that I could just
> > replicate the state management that is being done within the associated
> > OpenGL Chromium call.
> >
> > so I add a call glClearColorx, and look at the origional glClearColor,
> > and just replicate most of the function...
> >
> > It looks like this would be done in state_tracker/state_buffer.c
>
> Would it be feasible to simply translate the glFoox functions into the
> corresponding conventional OpenGL functions at the dispatch layer?
> That is:
>
> void glClearDepthx(GLclampx value)
> {
> glClearDepth(FixedToDouble(value));
> }
>
> That could be implemented in the opengl_stub/* files fairly easily, I
> think, without having to touch the rest of the system.
>
> I haven't looked at the ES functions closely enough to know if there's
> any potential pitfalls.
I'm going to spend the rest of the day stepping through the debugger to
get a better feel for what's going on inside chromium -- to avoid
getting too deep into a discussion and only guessing a the details.
My first thoughts on the above are this though:
void glClearDepthx(GLclampx value)
> {
> glClearDepth(FixedToDouble(value));
> }
>
>
This would give chromium the ability to look like gl-es to gl-es
applications, and render on OpenGL targets. It would also allow the
entire chromium system, spu's etc to function -- but would it give the
ability to render to gl-es targets?
I would like to be able to write some SPU's to do some analysis on gl-es
systems, so it might be best to have more of an "es-native" version of
chromium -- but this might break spu's etc. within the system, and force
a gl-es version of many components.
Anyway I'll have a more informed opinion soon.
> I haven't looked at the ES functions closely enough to know if there's
> any potential pitfalls.
Offhand this looks good. Some early examples of the es gl.h were missing
the glGet commands (and chromium might like to have these available) but
I believe that the spec says that they should be there.
>
> -Brian
|
|
From: Brian P. <bri...@tu...> - 2004-09-17 20:22:18
|
James Amendolagine wrote:
> On Thu, 2004-09-16 at 18:46, Brian Paul wrote:
>
>>James Amendolagine wrote:
>>
>>>On Thu, 2004-09-16 at 13:41, Mike Houston wrote:
>>>
>>>
>>>>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...
>>>
>>>Actually I believe it's EGL..
>>>
>>>
>>>By the way, I've just started working with Chromium (a couple of weeks
>>>ago), and I'm very impressed.
>>>
>>>
>>>So if no-one has done this before, I'll just jump in and do it myself.
>>>
>>>
>>>I don't understand the internals well enough yet to have a very useful
>>>opinion, but one of my concerns with adding the calls as extensions is
>>>will the SPU's still work? ie will the state tracking still be valid?
>>>
>>>
>>>When any of the OpenGL version of these ES calls are made:
>>>glClearColorx
>>>glClearDepthf
>>>glClearDepthx
>>>glColor4x
>>>glDepthRangef
>>>glDepthRangex
>>>
>>>I imagine that chromium records the state. I guess that I could just
>>>replicate the state management that is being done within the associated
>>>OpenGL Chromium call.
>>>
>>>so I add a call glClearColorx, and look at the origional glClearColor,
>>>and just replicate most of the function...
>>>
>>>It looks like this would be done in state_tracker/state_buffer.c
>>
>>Would it be feasible to simply translate the glFoox functions into the
>>corresponding conventional OpenGL functions at the dispatch layer?
>>That is:
>>
>>void glClearDepthx(GLclampx value)
>>{
>> glClearDepth(FixedToDouble(value));
>>}
>>
>>That could be implemented in the opengl_stub/* files fairly easily, I
>>think, without having to touch the rest of the system.
>>
>>I haven't looked at the ES functions closely enough to know if there's
>>any potential pitfalls.
>
>
> I'm going to spend the rest of the day stepping through the debugger to
> get a better feel for what's going on inside chromium -- to avoid
> getting too deep into a discussion and only guessing a the details.
>
>
>
>
> My first thoughts on the above are this though:
> void glClearDepthx(GLclampx value)
>
>>{
>> glClearDepth(FixedToDouble(value));
>>}
>>
>>
>
>
> This would give chromium the ability to look like gl-es to gl-es
> applications, and render on OpenGL targets. It would also allow the
> entire chromium system, spu's etc to function -- but would it give the
> ability to render to gl-es targets?
No. That would be a lot more work. Going through all of Chromium and
disabling the non-ES functions would be too much work to even
consider. Despite all the Python auto-code generation (derived from
the API description file), there's lots of hand coding that would be
effected.
One potential short-cut would be to modify the render SPU so that
calls to non-ES functions would get no-op'd and others (such as
glClearDepth) would get translated into the ES counterparts (such as
glClearDepthx).
-Brian
|
|
From: Mike H. <mho...@gr...> - 2004-10-11 17:14:00
|
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 > |
|
From: James A. <ja...@it...> - 2004-10-11 17:21:11
|
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 > > |
×
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