[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