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...