Fixed function pipeline replacement infrastructure follow up
Hi, As a follow up to the mail from last Sunday I now have a concrete implementation suggestion for an infrastructure for a fixed function pipeline replacement: What it mainly does is that it makes the state table a property of the shader backend, as well as the shader caps to keep GetDeviceCaps simpler. It also adds rudimentary functions for comparing the fixed function fragment processing settings. As an example implementation, the patchset is constructed around a fragment pipeline implementation using GL_ATI_fragment_shader. What is missing is dealing with vertex states, Henri has some code for that already. The data structure and comparison of pipeline states needs optimization. The already existing pipeline replacement using GL_NV_register_combiners and GL_NV_texture_shader should be moved into a separate shader backend. And obviously an implementation of vertex and fragment pipeline using ARB shaders and GLSL(that could be done as a gsoc project maybe) The GL_ATI_fragment_shader code is constructed bottom-up, so if the patches are applied as-is, it will lead to a temporary regression on ATI cards. Inverting this would be a major pain, so when sending it in I'll keep the extension disabled in patch 1, and enable it in a final last patch. The GL_NV_* stuff will work a bit different than atifs, arb and glsl, since we can configure all texture stages individually, so a stored program and state comparison is not needed. Instead we can keep the set_tex_op as it is, but the if(GL_SUPPORTED(...)) checks and related nastiness can be factored out. Maybe we can also get rid of setting up the texunit map every draw in some cases.
Am Sonntag, 9. März 2008 20:15:19 schrieb Stefan Dösinger:
What is missing is dealing with vertex states, Henri has some code for that already. The data structure and comparison of pipeline states needs optimization. The already existing pipeline replacement using GL_NV_register_combiners and GL_NV_texture_shader should be moved into a separate shader backend. An update on this, I think moving the GL_NV_texture_shader+GL_NV_register_combiners code into a separate shader model is pointless. I had a deeper look at the code again, and I think that the NVTS handling is well abstracted using set_tex_op vs set_tex_op_nvrc. GL_NV_texture_shader in turn is handled mostly in the activate_dimensions() function in state.c.
The situation isn't 100Q% desireable, but to get major improvements we'd need an nvts+nvrc exclusive backend, and keep both extensions out of the base one. This would mean a functional regression for cards that have nvrc but not nvts(Geforce 2 and earlier). Trying to keep nvrc functionality without nvts and still separating the code would mean massive code duplication with the gain of removing 4 or 5 if conditions. (Or alternatively adding a few more shader callbacks, one for each replaced if()) Once we implement real pixel shaders using those extensions we need a separate shader backend, but for the ffp part it will only hook the state_alphaop(), state_colorop() and sampler() functions to prevent the originals from killing the shader, but not modifying their functionality.
participants (1)
-
Stefan Dösinger