[4/22] WineD3D: A shader backend descriptor for the ati fragment shader backend
ivg231 at gmail.com
Wed Mar 19 01:46:07 CDT 2008
Stefan Dösinger wrote:
> 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
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?
More information about the wine-devel