Stefan Dösinger wrote:
Hi,
Given the past discussion, do you agree with the code now? Alexandre wants your OKs before applying the patches.
I am not familiar with the state table, atifs, or recent developments in the d3d codebase. That's why I suggested a diagram, so that everyone can understand the discussion. My concern is long-term maintainability of the shader API. I think the problem is with the definition of "shader backend".
The original intent, and the way it's currently used is: "A backend for the d3d shader pipeline ("d3d shader backend"), which happens to be implemented using some kind of gl shader".
The way this patchset is heading is: "A (gl shader backend), which implements both d3d shader and ffp pipeline, depending on the circumstances, through a mixed api"
I don't mind sharing the GL shader code to implement FFP or D3D shader pipelines - whether it's ATIfs, ARBfp/ARBvp, GLSL, or some other thing providing the implementation. What I do mind is sharing that code through the same API for both the FFP and D3D pipeline codepaths. This leads to combining APIs that don't belong together, and odd multiplexing like you have in patch 004 - forcing the shader path through atifs, even though atifs currently doesn't support handling shaders properly, and has to "borrow code" from other backends, and implement routing to the right one based on what flags are set.
Why do you need to reroute the shader path through atifs to support an unrelated set of functionality (ffp replacement)? Isn't it possible to have an ffp_backend, and a shader_backend (shader being the d3d shader), and you can implement both differently, with different APIs?
Ivan