[4/22] WineD3D: A shader backend descriptor for the ati fragment shader backend

[Ivan Gyurdiev]

Stefan Dösinger wrote:
>> 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.
>   
It looks to me as if shader_backend is being overloaded for many 
different purposes that are not really related to each other. Typical 
object structure is to group related data an functions in one place, but 
what's happening in shader_backend is that it has no data of its own, 
and it's a vtable routing between different GL extensions with the data 
being scattered across multiple different places.

    - some functions are related to management of a single shader and 
its resources [ state is BaseShader ]
    - other code manages the link between vertex and fragment shader [ 
glsl programs stored in the Device ]
    - other code manages a group of 2 shaders to handle some fixed 
function purpose [ _blt, using Device->shader_priv_data ]
    - now you want to replace the main fixed function fragment 
processing [ state is in the state table ]

I think it would be worthwhile to review all of this, and see if this 
organization makes sense.  Why aren't the functions grouped together 
with the data ? Why is some of the data in the device object ? Why are 
functions managing different data containers in the same vtable ?

I am no longer familiar with the details, but there's way too many 
things called "shader" by now - d3d shader, gl shader, this made up 
"shader_backend" that actually does fixed function stuff and represents 
neither.  Maybe it makes sense to create new object types - like a 
'pipeline', containing a 'vertex processor', 'fragment processor' (not 
necessarily implemented via shaders).  Maybe each of these should have a 
"fixed" and "dynamic" facing d3d API, but attach or detach to the 
pipeline in the same way. Maybe they can have different gl extensions 
"backend" implementing each.

> 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.
>   
Will take a look...