Warren wrote:What problems are there merging this with the pspgl in SVN?
Differences in approach, mainly. I won't speak for Holger, but here's my view:
I'm interested in incrementally improving PSPGL while trying to keep it useful and working at all times. Lots of stuff is missing, but the stuff that's there should work like "real" OpenGL, at least within the parameters of what we want to support. It should be easy to have the same source compile for a desktop system and on the PSP, as a useful development tool.
I'm also not particularly interested in micro-optimisations; I want the code to be high performance, but also readable and maintainable. It should be optimised in response to measuring real programs running. I expect that ultimately there'll be a fair amount of inline assembler, special cases, dynamically generated code and the like, but that's not much use while so much of the basic functionality is missing.
I want the code to be small and efficient, but code size isn't an overriding concern. At present all the .o's total about 55k; I don't know how much more this will grow, but I think 100k will be an absolute limit. Fortunately, a lot of this code will only be pulled in if you use the GL features it implements. The most important part of having small code size is making efficient use of the icache; this means putting all the hot code together and having short hot paths, but unused code doesn't matter so much.
There are also stylistic differences. For example, one of my early patches converts all the literal constants used for the command/register names into symbolic constants. I find this is essential to make the code readable, and it flushes out bugs on a regular basis. Also, my PSPGL is careful to put all its private symbols into a private namespace to prevent collisions with application symbols. Unfortunately this makes tracking the SVN version tricky because there are widespread collisions with my patches.