| I agree with Jon. The RENDERER string has always been
| implementation-dependent in every regard, and should remain that way. The
| benefit to Brian's proposal is the ability to parse the string to gather
| multiple pieces of information in a consistent manner. If this is a desired
| goal, rather than overload RENDERER, lets propose additional Gets which can
| be added as an extension.
I'd go back and ask the question of whether there is a real
problem to be solved here? Are we trying to invent cap bits?,
make sure that driver writers can provide arbitrary useless
information, etc? The hardware config, is the RENDERER string It
unclear whether the other information can really be useful
independent of the value in the RENDERER string. (does an app
care if the board is pci33, pci66, agp1,2,or 4x without knowing
what kind of board it is?). The idea was that the renderer
string could be used as a key into a database of capabilities
and it should unambiguously describe the configuration. To that
end we found it useful to encode things like the number of
geometry processors, number of rasterization processors, texture
memory, in the string, but only for the purposes of
distinguishing between configurations.
