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
>>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[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.