Stefan Dösinger wrote:
Alexandre didn't commit the patch, I think we should come to an agreement on this issue, otherwise it is going to come up again and again.
The fundamental issue is pretty straightforward - not sure why it's so difficult to come to an agreement.
- You want to mix and match vertex and fragment GL backends - The only maintainable way to do that is to define an interface between vertex and fragment objects
- You're concerned about the interface constraining the ability of fragment to talk to vertex - Write a smarter interface, I also suggested an object to manage it (linker).
You can't have it both ways - ability to mix and match backends, and unconstrained interface. The interface doesn't have to be "the lowest common denominator" - it could be the highest common denominator if properly written. As Henri pointed out the fact that both GL and the hardware are vertex/fragment aligned naturally suggests we should break up things the same way. Even the D3D programmable pipeline is broken up this way (there are Pixel and Vertex shader objects) - and the fixed pipeline is going away, so if anything we should move away from its interface.
- You want to replace the fixed pipeline using GL shaders. - Then replace the fixed pipeline - this has nothing to do with the programmable pipeline, therefore should not affect any programmable pipeline interfaces.
You've pointed out that shader_backend_t is more aligned to a GL extension than it is to a D3D shader. If that's the case I see little value to having that interface - it will just cause confusion as unrelated functionalities are packed into it. The disparity between GL extensions will get greater as we try to add new features using a particular extension, and we'll see a lot of functions that are just empty forwards to other "shader backends", since they don't support something themselves.
Ivan