[4/22] WineD3D: A shader backend descriptor for the ati fragment shader backend
Stefan Dösinger
stefan at codeweavers.com
Wed Mar 19 20:13:14 CDT 2008
> I'll get back to you on that later tonight, need to think about this
> some more - way late for work right now... (thanks to you!)
>
> However, yes, I think there needs to be distinction between a standalone
> shader concept, and a pipeline concept, which is concerned with linking
> several multifunctional shaders together - your "uber-shader-backend".
> Lack of distinction on this point is causing all this confusion.
Cool, I'm looking forward to suggestions.
Meanwhile, I've separated the ATIFS implementation and the shader backend
changes in my patches. The result is attached. The patches
named "1", "2", ... will be merged together to avoid regressions due to
partial implementations, and they need some reordering. I've hacked that
together during my train ride, so I've no idea if it really works.
I've separated the shader model changes and the atifs implementation to make
Alexandre happy. I'm now also enabling ATIFS only if ARB vertex shaders are
enabled, pixel shaders not disabled, GLSL not supported and
ARB_fragment_program not supported. Thus atifs only inherits from the arb
backend, which avoids the 3 shader backend structures and makes dealing with
the private data easier. So I think it partially addresses your concerns.
atifs still has to route vertex processing through the ARB backend, but we
will need that if we implement d3d pixel shaders using atifs, unless we split
up vertex and fragment shader processing backends(So separating fixed
function and programmable won't help there).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0.tar.bz2
Type: application/x-tbz
Size: 43138 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20080320/b97692ad/attachment-0001.bin
More information about the wine-devel
mailing list