[Bf-viewport] OpenGL low level shader API proposal

[Antony Riakiotakis]

Hi Brecht,

That's kind of what I'm proposing :).
>
> But the design is different than yours. The funky shader example is a
> use case specific shader interface.
>
> * funky_shader_new() would compile the shader with GPU_shader_create()
> * funky_material_params_finalize() would set uniforms with functions
> like GPU_shader_uniform_vector()
>
> That's fine. Any design goes that doesn't requires us to re-query the
uniform locations every time after binding a shader

>
> > LightParams *lp = interface->getLightParams();
> >
> > lp->light_pos = pos;
>
> What I'm missing here is the ability to reuse a set of shader
> parameters. Consider for example the current GLSL node materials, if
> you have multiple materials on an object then their shaders could
> share the same per object GPUShaderParameters.
>
> The other thing is that GPUShaderParams would be immutable once
> created, so that per object GPUShaderParameters could be uploaded to
> the GPU once and cached. With your interface the bind() call is
> required to re-upload the data every time? I would like the parameters
> to be validated and ready before that.
>

Every time the relevant data changes. Light position was a bad example of
that, let's say transform is a better example here. I don't think we need
data to be immutable on the GPU, just cached.
Keep in mind that when rebinding a shader, we are required to rebind all
the uniform state. This is not as bad with uniform buffer objects but for
GL 2.1 it makes sense to have a way to bind all data.


> > GPUAttribute *p = interface->getPositionAttribute();
> >
> > GPU_bind_vertex_buffer(p, offset, stride, etc...);
>
> I think we need a way to have both different types of meshes (cddm,
> subsurf, metaballs, ..) and different types of shaders (GLSL, solid
> lighting, matcaps, ..) working together.
>
> For different type of meshes, the ongoing derivedmesh refactor that I
started this summer aims at that.

So we need a general mechanism, where for all types of shaders you can
> get the required attributes, for which I proposed using
> GPUShaderVertexAttribs. It's not really clear to me if in this example
> getPositionAttribute() is a function specific to one shader type or
> available for all shader types?
>
>
Yes GPUShaderVertexAttribs is perfect for that. The idea is that the shader
requests vertex buffers with customdata, the derivedmesh fills those
buffers (or sets the attribute to a reasonable constant value if they are
missing)

> /* bind shader */
> > shader->bind();
> >
> > /* sets attributes appropriately and effectively */
> > interface->bind();
> >
> > /* draw */
> > GPUdraw(numeElements, drawType)
>
> I'm specifically trying to avoid binding and state, to avoid state
> accidentally leaking, or having to deal with verbose and error prone
> unbinding and unsetting of state. If there is only a small amount of
> state then it's not as bad, I just prefer to pass it explicitly to the
> draw function.
>
> Fair enough

>
> I can see that with my proposal it's not as clear which parameters and
> attributes you need to pass. Having a data structure that has both a
> pointer to the GPUShader and a set of GPUShaderParams would be simpler
> to use. The funky shader example API could be like this:
>
> GPUShaderParams *funky_light_params(FunkyLight light[], int num_lights);
> GPUShaderInstance *funky_shader_instance(FunkMaterialParams *funky,
> GPUShaderParams *shared_light_params);
>
> And then you pass only that GPUShaderInstance* to the draw function.
>
>
It's clearer, though again I don't know if we can really enforce parameters
to be constant (as discussed above). This is where a more fine-grained
approach is better, even though it's more error prone as you said.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-viewport/attachments/20151205/091106e5/attachment.htm