I gave some more thought to the matter of finding out about software rendering, and decided to start a new, unlcattered thread with these thoughts.
I see two different uses for finding out about software rendering: detection and prevention. Detection means finding out that software rendering took place. Prevention means finding that software rendering will take place before it happens, so that the program can adapt, and not cause this condition.
I will start with detection, which I currently see as more important, and which should be easier to implement. My own experience, and a lot of questions in the “advanced OpenGL” forum, will testify that getting software rendering is quite common, yet it’s often not recognized, and even if we guess that this is the problem, there is no way to verify this. It would therefore be valuable to know that software rendering did take place. This is helpful not only for the debug and in-house testing, but the test can be included in the software to allow a user who suffers from a case of “very slow rendering” to diagnose the problem, and send a meaningful report to the developer (“your f*&^ing game is using software rendering on my expensive overclocked GeForce3”).
Detecting that software rendering had occurred could be done using a mechanism similar to glError, as suggested by Dodger in the original thread. That is, when software rendering takes place, a flag is set, and it can be read (and at the same time reset) by the program. I think that this should not be difficult to implement - the ICD can set this flag when it performs software rendering. The flag can’t be guaranteed to always be valid (by this I mean, you can’t really tell when it will be set), but it should be valid after a call to glFinish() or equivalent. (It’d be good to have other ways to guarantee it’s validity - perhaps similar to NV_fence - to allow to find more easily where software rendering happened within the frame.)
While I’m using the term “software rendering”, it’s actually made of several different operations. In the original message I used it for “triangle rasterisation”, but it could also mean “line rasterisation”, “buffer operations” and “vertex processing”. By software buffer operations I mean operations like copy to texture and using the accumulation buffer, that use copying from card memory to system memory, and would not have done so in a full hardware implementation. By “vertex processing” I mean T&L and vertex shaders. (Are there are other categories you can think of?) These different categories should be detectable within the flag (as different flags, or bits within one flag).
Now to prevention. While detection can allow finding out that software rendering had happened, it doesn’t make it easy to pinpoint the cause of software rendering. Being able to query for a software rendering condition before it happens can allow diagnosing the problem better, and possibly to eliminate software rendering seamlessly at runtime, by eliminating some features. Implementing a short “prevention” style code after context creation can help identify the problematic condition of software rendering, without the need for doing rendering, which can be invaluable for testing when some features are used only in certain places in the program (such as only in certain scenes).
The main problem with this is that it’s more difficult to implement. There is no way to guarantee that software rendering will or will not take place, as it highly depends on what the program is doing. However, there are cases where it is possible to say “a feature you have asked for will result in software rendering if you use it.” This is naturally only possible when the user has asked for a feature. For example, any OpenGL 1.2 context will provide 3D textures. Since this feature is not specifically requested, it can’t be reported to be in software. However, asking for EXT_texture3D can be made a specific request, and this guarantee (that software rendering will be used for it) can be made for it.
Such an indication that software rendering will happen (and I’m mainly talking about triangle rasterisation) can be made available in both mode selection (WGL) and as a function for extension querying. In addition, a query to test whether the current state will lead to guaranteed software rendering can be made available. For example, if line smoothing is enabled, a query of “will drawing lines result in software rendering” should return true if this is what line drawing will do. The result of this query should be interpreted as “yes” or “I don’t know” and not “yes/no”.
While prevention is more difficult to implement than detection, it should still be quite possible. The “is guaranteed to be software rendering”, or “yes / don’t know” interpretation, allows the ICD programmers to not test conditions that may be impossible or just too complicated to test. Yet, this can provide the benefits of prevention in most cases, and in the cases when this is not possible, it would always be possible to know in retrospect that software rendering occurred, if detection is also available.
I’d appreciate comments, especially from Matt and others “in the know”.