The Chromium Project

Hi Alan,

> With regard to adding OpenGL 1.2, 1.3 etc to the CR_GL.H and GL.H
> header files to start propogating the functions throughout 
> Chromium.....
> 
> There's a stickling point with extensions that have existed in prior
> GL versions and have become standards in later versions. Hence,
> an example...
> 
> A simple two crserver setup with the tilesortSPU. Now, If we
> have 1 renderSPU that can do GL 1.3 and 1 that does GL 1.2 with
> the ARB extension we need to pose as one for the purposes of
> the client. So, lowest common denominator shows we should elect
> 1.2 and the ARB extensions. Thus, we get to a problem at the
> renderSPU when dispatching and having to correctly push the ARB
> call to the 1.2 engine and the real 1.3 call to the 1.3 engine.
> 
> So it's not as simple as just adding the new functions to the existing
> header files in glapi_parser, we really need to think about the
> dispatcher and how we should be fixing up the renderSPU's to
> handle this. We also need a mechanism to check the GL version now
> and propogate that as limits through Chromium, just like the 
> extensions
> are currently handled.
> 
> It's already a concern in respect of the glTexImage3D / 3DEXT function
> that's recently been added.

Not to confuse the issue, but here's are some patch files that add
support for glTexSubImage3D and glCopyTexSubImage3D.  In light of your
comments, I've not included the respective EXT versions, but they
*should* now be trivial to implement. . .

As before, we've tested these calls with a few "quick-and-dirty" test
apps in a simple one-to-one configuration.  We're still hoping to get
some feedback from others with the need for 3D texturing before moving
on to the bigger issues.  I succeeded today in running the simian volume
rendering tool (http://www.cs.utah.edu/~jmk/simian) with Chromium in a
simple one-to-one configuration.  There are a few more issues I need to
take care of before moving onto distributed 3D textures, but hopefully
it won't be long.

The patches were built against the CVS code as of 1:15 pm (MNT time)
today, Friday, August 30th.  Please let me know if you have any
problems.

Thanks!

Christiaan

Alan Hourihane wrote:
> Now, If we have 1 renderSPU that can do GL 1.3 and 1 that does GL 1.2
> with the ARB extension we need to pose as one for the purposes of the
> client.  So, lowest common denominator shows we should elect 1.2 and the
> ARB extensions.

Dumb question: can we pose as both GL 1.2 with the extension and GL 1.3 at
the same time?  That is, have both calls map to the same functionality.

> Thus, we get to a problem at the renderSPU when dispatching and having to
> correctly push the ARB call to the 1.2 engine and the real 1.3 call to
> the 1.3 engine.

I wonder if we can make the constraint that, if you intend to use
functionality like this, all of your render SPUs must have the same level
of OpenGL compliance.  That should minimize the dispatch issue, though I'll
have to think about this some more.

> We also need a mechanism to check the GL version now and propogate that
> as limits through Chromium, just like the extensions are currently
> handled.

We will continue to need this.

-Sean

__
seanahern@...

On Fri, Aug 30, 2002 at 05:34:20PM -0700, Sean Ahern wrote:
> Alan Hourihane wrote:
> > Now, If we have 1 renderSPU that can do GL 1.3 and 1 that does GL 1.2
> > with the ARB extension we need to pose as one for the purposes of the
> > client.  So, lowest common denominator shows we should elect 1.2 and the
> > ARB extensions.
> 
> Dumb question: can we pose as both GL 1.2 with the extension and GL 1.3 at
> the same time?  That is, have both calls map to the same functionality.
 
We can't pose as both to the client app. Although we can map the
functionality internally within Chromium. What I'm saying is, that's
it's not as simple as just adding functions to CR_GL.H and GL.H to
do this. We need to rework the dispatcher to do the mapping.
I've spoke with Brian offline about this, and we can do it, but it
might mean replacing these two header files with something like
the approach Mesa takes with it's APIspec file, which makes it easier
to map extensions onto their standards.

> > Thus, we get to a problem at the renderSPU when dispatching and having to
> > correctly push the ARB call to the 1.2 engine and the real 1.3 call to
> > the 1.3 engine.
> 
> I wonder if we can make the constraint that, if you intend to use
> functionality like this, all of your render SPUs must have the same level
> of OpenGL compliance.  That should minimize the dispatch issue, though I'll
> have to think about this some more.
 
I don't think we can do that, you could make the same restriction about the 
graphics cards used in the renderSPU's too. I think that's the wrong approach,
and we need to stay generic. As Chromium has really only been doing 1.1
until now, this really hasn't been a problem for the majority of
commodity hardware, but with 1.3 and 1.4 it will be. I think it's
too big a restriction to force people to upgrade drivers or possibly
replace hardware.

Alan.

On Saturday, August 31, 2002, at 06:01 AM, Alan Hourihane wrote:
> We can't pose as both to the client app. ... it might mean replacing 
> these two header files with something like the approach Mesa takes 
> with it's APIspec file, which makes it easier to map extensions onto 
> their standards.

That was my next thought, that Brian has to have covered this territory 
to some extent in Mesa.

> I think that's the wrong approach, and we need to stay generic. ... I 
> think it's too big a restriction to force people to upgrade drivers or 
> possibly replace hardware.

Yeah, that's true.  You might want to run Chromium on a rather 
heterogeneous cluster.  Fair enough.

-Sean

--
ahern@...

On Fri, Aug 30, 2002 at 03:04:57 -0600, Christiaan Paul Gribble wrote:
> Hi Alan,
> 
> > With regard to adding OpenGL 1.2, 1.3 etc to the CR_GL.H and GL.H
> > header files to start propogating the functions throughout 
> > Chromium.....
> > 
> > There's a stickling point with extensions that have existed in prior
> > GL versions and have become standards in later versions. Hence,
> > an example...
> > 
> > A simple two crserver setup with the tilesortSPU. Now, If we
> > have 1 renderSPU that can do GL 1.3 and 1 that does GL 1.2 with
> > the ARB extension we need to pose as one for the purposes of
> > the client. So, lowest common denominator shows we should elect
> > 1.2 and the ARB extensions. Thus, we get to a problem at the
> > renderSPU when dispatching and having to correctly push the ARB
> > call to the 1.2 engine and the real 1.3 call to the 1.3 engine.
> > 
> > So it's not as simple as just adding the new functions to the existing
> > header files in glapi_parser, we really need to think about the
> > dispatcher and how we should be fixing up the renderSPU's to
> > handle this. We also need a mechanism to check the GL version now
> > and propogate that as limits through Chromium, just like the 
> > extensions
> > are currently handled.
> > 
> > It's already a concern in respect of the glTexImage3D / 3DEXT function
> > that's recently been added.
> 
> Not to confuse the issue, but here's are some patch files that add
> support for glTexSubImage3D and glCopyTexSubImage3D.  In light of your
> comments, I've not included the respective EXT versions, but they
> *should* now be trivial to implement. . .
> 
> As before, we've tested these calls with a few "quick-and-dirty" test
> apps in a simple one-to-one configuration.  We're still hoping to get
> some feedback from others with the need for 3D texturing before moving
> on to the bigger issues.  I succeeded today in running the simian volume
> rendering tool (http://www.cs.utah.edu/~jmk/simian) with Chromium in a
> simple one-to-one configuration.  There are a few more issues I need to
> take care of before moving onto distributed 3D textures, but hopefully
> it won't be long.
> 
> The patches were built against the CVS code as of 1:15 pm (MNT time)
> today, Friday, August 30th.  Please let me know if you have any
> problems.

Testing these now. Thanks.

Alan.

Alan Hourihane wrote:
> On Fri, Aug 30, 2002 at 05:34:20PM -0700, Sean Ahern wrote:
> 
>>Alan Hourihane wrote:
>>
>>>Now, If we have 1 renderSPU that can do GL 1.3 and 1 that does GL 1.2
>>>with the ARB extension we need to pose as one for the purposes of the
>>>client.  So, lowest common denominator shows we should elect 1.2 and the
>>>ARB extensions.
>>
>>Dumb question: can we pose as both GL 1.2 with the extension and GL 1.3 at
>>the same time?  That is, have both calls map to the same functionality.
> 
>  
> We can't pose as both to the client app. Although we can map the
> functionality internally within Chromium. What I'm saying is, that's
> it's not as simple as just adding functions to CR_GL.H and GL.H to
> do this. We need to rework the dispatcher to do the mapping.
> I've spoke with Brian offline about this, and we can do it, but it
> might mean replacing these two header files with something like
> the approach Mesa takes with it's APIspec file, which makes it easier
> to map extensions onto their standards.
> 
> 
>>>Thus, we get to a problem at the renderSPU when dispatching and having to
>>>correctly push the ARB call to the 1.2 engine and the real 1.3 call to
>>>the 1.3 engine.
>>
>>I wonder if we can make the constraint that, if you intend to use
>>functionality like this, all of your render SPUs must have the same level
>>of OpenGL compliance.  That should minimize the dispatch issue, though I'll
>>have to think about this some more.
> 
>  
> I don't think we can do that, you could make the same restriction about the 
> graphics cards used in the renderSPU's too. I think that's the wrong approach,
> and we need to stay generic. As Chromium has really only been doing 1.1
> until now, this really hasn't been a problem for the majority of
> commodity hardware, but with 1.3 and 1.4 it will be. I think it's
> too big a restriction to force people to upgrade drivers or possibly
> replace hardware.


I'm not too worried about mapping extension functions to 1.x core functions from
the point of view of heterogeneous clusters.  All the GL vendors I know of keep
advertising extensions after they've become core features.  For example, the
ARB_multitexture extension will be advertised for years to come even though it's
been a standard feature since OpenGL 1.2.1.

The problem I'm concerned about is internal function aliasing.  For example,
ARB_multitexture defines 32 new functions of the form:
glMultiTexCoord[1234][sfid][v]ARB().  OpenGL 1.2.1 and later have the same 32
functions, but without the "ARB" suffix.  It doesn't make sense to have 64 of
these functions when 32 would suffice.

We need a way to establish these aliases when generating the API dispatcher.
Actually, the Linux_i386_exports.py script already does this for the multitexture
extension.  I think that we need to simply extract that code into a new module
which can be used for C dispatch, IRIX, FreeBSD, etc.  Then add a bunch of the
newer function aliases.

The getprocaddress.py script should be updated to handle aliases too.

Alan and I get take care of this.  We also plan to add support for some of the
NVIDIA extensions that people are interested in.

-Brian