This is the first of a couple of patch sets which intend to impose some new requirements on GL support. In total I intended to submit patches to require these things:
* EXT_framebuffer_object
* ARB_texture_non_power_of_two (including WINED3D_GL_NORMALIZED_TEXRECT)
* GLSL 1.20
And, unless demand to the contrary is demonstrated, to remove the code paths that care about their absence. This means that the "OffscreenRenderingMode" setting, the ARB shader backend, and all non-GLSL fixed-function pipeline backends will be removed.
All of these extensions are at least 17 years old at the current date.
--
Some explanation may be warranted. In general Wine is reticent to impose heavy requirements on users' software or hardware, and when it comes to Direct3D we have been especially conservative in this respect.
Critically, this is not necessarily a matter of being realistically concerned about hardware or software still in use—although we do tend to be more conscious than most projects about some users' long-term support requirements—but more importantly that we do not waste time removing features just because they are believed to be obsolete.
Even where related code is being touched, and hence removing code may seem helpful, it is often easy and generally better to abstract away and "quarantine" that code. The ARB shader backend, for example, is very much quarantined in this way; it is not difficult to modify the GLSL backend and leave the ARB backend alone.
With that said, as far as the listed extensions are concerned, there are some reasons I would like to impose these requirements anyway.
* In the first case, not all code can be easily "quarantined". Support for ORM_BACKBUFFER, in particular, is very invasive, and affects a large number of disparate places in small ways, rather than being a single alternate path. Support for NP2 fixup is similar, although perhaps a bit less invasive than ORM_BACKBUFFER.
* Even with code that can be quarantined, there are some smaller, but I believe nonnegligible, costs to keeping that code around. Speaking in concrete terms so as to be more understandable, if I wish to refactor the way states are tracked and invalidated, I need to do some work to either refactor other backends the same way as the GLSL backend (e.g. 5126), or adjust the quarantine so that the old path is kept around just for quarantined code.
Doing the latter has a tendency to build up and make the code difficult to follow. A new contributor can easily get led down the wrong path that way.
* Somewhat relatedly, when some functionality or internal helper needs to be fixed, a contributor (and the maintainer) needs to then either spend time fixing *every* backend, or know that some backends don't matter and ignore them [if ignoring is even feasible for a given change].
The latter can be difficult to discover, especially for a new contributor, and even then it takes time—and, in a malleable sense, maintenance burden—to look through code and confirm that it doesn't matter.
To be clear, this is not meant as rationale to start removing anything and everything. As with all things, these are tradeoffs, between all of the above reasons to keep or remove any given code. The three listed GL extensions are the only three which I believe, at the moment, that there is enough utility in requiring, and little enough reason to keep.
This was a matter of some internal discussion among Direct3D contributors. However, there is not really a consensus — or at least not an enthusiastic consensus — that this is desirable. The above is an attempt to summarize the concerns and justify why I personally think this is a good idea. But it's a difficult decision, and that's at least in part because this code is the best translation layer from old Direct3D to *contemporaneous* GL, and it's sad to see that go.
At the same time, in the world of version control, no code is ever truly gone. Hence perhaps the most simple argument to make is that if we are really going to *maintain* this code, that will take extra work—work which at this point I really would rather not do—and if we are not going to maintain it, then we're not offering any more utility than an actual git archive.