One great (and maybe impossible) thing in a future OpenGL version would be to tell GL to compute some feature by software, while other things would remain hardware accelerated. For example :
glForceSoftware(GL_POLYGON_OFFSET_POINT);
This would essentially allow developpers to tune their applications regarding the bugs of the current drivers. For example:
// we know the CompanyName’s drivers
// don’t actually support the
// GL_POLYGON_OFFSET_POINT feature
if(driverVendor==“CompanyName”)
glForceSoftware(GL_POLYGON_OFFSET_POINT);
Thus the day CompanyName release a good driver which has no bug related to that feature, the developer only has to remove his test (Of course, this test could be more accurate by taking into account the version of the driver, etc).
Because 50% of OpenGL development is about making things work everywhere, I think such strategies are the keys to clean GL code and better QA. How many GL developers did reinvent the wheel (ie: rewrote a software mode for some features) just because some drivers fail doing the belonging operation?!
I’m afraid what you ask is not reasonable simply because there’s no software/hardware layer visible from OpenGL. This abstraction is one of the strength of OpenGL, even though many have claimed (and some still claim) that it is a weak point.
You tell to force software renderer… but which software renderer ? The MicroSoft or Mesa renderer ? don’t tell me that doesn’t contain bugs please.
And you can’t render one half of your frame with eg ATI hardware renderer and the other half with eg MESA software renderer. This would be possible IF both ATI and MESA worked toghether to make it working, which I doubt because the investment for such compatibility would be better used for debugging standalone drivers.
Debugging is an honourable thing, but I think it’s more than what OpenGL is made for.
In fact, IMO, it’s up to the driver developers to propose to deactivate (or switch to a safer method, software) some of their features (in some kind of control panel) when they feel it is reasonable to do so. That’s what NVIDIA does, for instance, when they propose the NV30 features in their new drivers : if you want to play with NV30 then go for it otherwise click on the corresponding checkbox and it won’t bother you anymore.
[This message has been edited by vincoof (edited 09-12-2002).]
You tell to force software renderer… but which software renderer ? The MicroSoft or Mesa renderer ?
The software renderer in the driver perhaps?
Every hardware driver has to have a more or less complete software renderer, unless the hardware can do everything, under every possible combination of states, in hardware.
That’s right that some features are processed in software for compatibility issues.
But allowing such glForceSoftware function means that all functions can be emulated in software.
Moreover it is not clear how software can replace hardware.
For instance, what does mean glForceSoftware(GL_DEPTH_TEST) ? For sure the depth comparisons will be made in software, but Is the buffer stored in software memory or hardware memory ? Is the depth mask, depth offset (polygon offset) done by the software or the hardware ?
I agree that forcing all functions to software mode is somewhat utopian. But there would be a subset of emulated features which you can pass to glForceSoftware. A good example is the polygon offset feature, which is not correctly handled by a large number of drivers.
About the “setting panel” option, I’d agree only if there is a way for the developer to script the panel, in order to do the job once. Otherwise each user would have to tune his drive manually himself. And we all know this kind of ‘tuning’ is for developers and power users only.
About choosing which software renderer to use, there could be a state variable for this. The default would be the most common on user’s computer, but developers would change it with: glChooseSoftware(<mesa id> )
But I’m not sure this would be a good thing, because common users just use the default software renderer (they don’t know they can change it).
In conclusion, my viewpoint is all about users. For now, OpenGL is great for developers but not for users because of driver issues. My suggestion is a way to bring back these problems to the developers by giving them a kind of control of what might happen on the users’ computers. Nothing more.
You realize you’re proposing a feature for the sole purpose of fixing broken drivers, correct? As such, you’re taking the wrong approach. Perhaps you should be dealing with the particular driver implementers (or finding a way to work around the problem if they are unwilling to fix the behavior).