Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
From: Chris Burns <cburns@ta...> - 2008-01-16 16:07:17
throughout the code I'm finding files with the name "*_special" that
list some subset of the OpenGL API. I'm having a hard time deciphering
for each of these files what criteria causes a function to end up
here. They are obviously manually constructed.
This project is starting to look bigger than I had originally thought,
mostly due to my lack of familiarity with Chromium's source code. Is
there any interest by anyone on this list to collaborate?
For the record, the project is to get Chromium to support the four ARB
extensions that are used to support GLSL (GL_ARB_shader_objects,
From: Robert Ellison <papillo@tu...> - 2008-01-16 19:21:04
> throughout the code I'm finding files with the name "*_special" that
> list some subset of the OpenGL API. I'm having a hard time deciphering
> for each of these files what criteria causes a function to end up
> here. They are obviously manually constructed.
The "*_special" files are typically used with Python code generation scripts,
and indicate a function that for some reason or another cannot be handled with
automatically generated code, and instead must be handled with "special" code.
Sometimes this is because the code generation script isn't complete (and
complex) enough to handle all possible generic function specifications (from
APIspec.txt); sometimes it doesn't make sense to spend hours carefully crafting
the code generator to handle just a few unusual cases that you could otherwise
code in a few minutes.
Sometimes it's because APIspec.txt doesn't include just the right classification
code for a group of functions that could be used to automatically generate code
for them; the only alternative to defining a new classification and going
through every function in APIspec.txt to figure out which functions need the
classification (a very pervasive action) is to create a "*_special" file.
Sometimes it's because the whole point of a generated SPU is to provide special
implementations of just certain functions, while providing common handling for
all others (e.g. the "expando" SPU).
Sometimes it's because some functions or classes of functions really need
special handling that can't be automated for a given use.
In general, unfortunately, you have to have a pretty intimate understanding of
what sort of code generation is going on and why in order to figure out what
belongs in a "*_special" file. That's hard enough if you're modifying an SPU,
but quite a bit more difficult if you're adding functions to APIspec.txt.
As a first pass, I'd recommend the same thing Brian did: find functions that
behave like the new functions do, and make their entries in APIspec.txt and
"*/*_special" files similar. As you test, you'll inevitably find places that
you missed or incorrect categorizations; fix the ones that you find, and the
next guy will fix the ones that he finds, etc...
Tungsten Graphics, Inc.