[4/22] WineD3D: A shader backend descriptor for the ati fragment shader backend
ivg231 at gmail.com
Wed Mar 19 23:51:23 CDT 2008
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...
More information about the wine-devel