[Bf-viewport] OpenGL low level shader API proposal

[Antony Riakiotakis]

Just a side note here:

The previous interface based approach can also allow us to sort interfaces
to groups with similar inputs and bind sub-parts of interfaces to minimize
state changes, something which is quite desirable in my opinion.

On 5 December 2015 at 10:50, Antony Riakiotakis <kalast at gmail.com> wrote:

> Hi Brecht, thanks for the work!
>
> A few improvements, if I may:
>
> * Transform is no different than a GPUShaderParam now. One can easily
> think of UI shaders where we just work with 2D coordinates
>
> * As Ton said above, not all input, such as basic color, comes through
> vertex buffers. We need a way to set a constant state for an attribute.
> This is easily supported in GL by glAttribute* calls (which are not
> deprecated :) ).
>
> * Passing all parameters to the shader like that:
>
> draw(shader, params, vertex_buffers, transformation);
>
> Still feels bound to a certain implementation/assumptions. What we would
> like, imo, is a way for the shader type itself to advertise its inputs,
> then client code connect data to those inputs as it wishes.
>
> This can be achieved with a two layer system:
> We have a low level shader compilation, binding, etc system, and we have a
> use-case-specific shader interface which sits on top of it.
>
> So the whole workflow looks something like that:
>
>
> 1) compile shader
> 2) client code obtains input slots (attributes, textures, uniforms) from a
> use-case specific interface.
> For instance, for a lighted mesh, client code can request a specific
> "light" struct from the inteface.
> This can be set to the shader through glUniform calls or by using a
> uniform buffer etc, etc by the inteface. It is of little matter to the user.
> Client code needs to set if attributes come from vertex buffers or
> constants, which can be easily set if GLVertexAttrib struct has some extra
> state.
> 3) Interface objects can be cached and reused.
> 4) draw call sequence is now:
>
> ----------------------
> shader->compile()
>
> /* gets relevant indices for attributes, uniform blocks etc, needs to
> happen just once after shader compilation */
> interface->aqcuireFromShader(shader);
>
> LightParams *lp = interface->getLightParams();
>
> lp->light_pos = pos;
>
> GPUAttribute *p = interface->getPositionAttribute();
>
> GPU_bind_vertex_buffer(p, offset, stride, etc...);
>
> GPUAttribute *n = interface->getNormalAttribute();
>
> GPU_constant_attrib(n, value);
>
> /* keep interface for later use, do more stuff */
> ...
>
> /* bind shader */
> shader->bind();
>
> /* sets attributes appropriately and effectively */
> interface->bind();
>
> /* draw */
> GPUdraw(numeElements, drawType)
> -----------------------------
>
> This decouples the low level stuff from the client code stuff quite
> effectively imo.
>
> * For more complex systems, like the node-based shaders (which I hope can
> be the only display mechanism for the meshes in the future), we need to
> have a more generic system of course.
>
> The current GPU codegen module already has most components there. The only
> addition to the previous interface based design is that Attribute
> components, now have an extra field which is about the type of customdata
> it needs. And our code already does that :). It just needs to set a
> constant value for meshes that do not have the customdata that are
> requested available (maybe we already have that? Can't remember off hand).
>
> I think that's all my input for now.
>
> On 5 December 2015 at 03:02, Brecht Van Lommel <brechtvanlommel at gmail.com>
> wrote:
>
>> Hi all,
>>
>> I've written a rough proposal for the low level shader API that all
>> OpenGL shaders would use, both for mesh and UI drawing.
>> http://wiki.blender.org/index.php/Dev:2.8/Source/OpenGL/Shaders
>>
>> It builds on data structures and APIs that are already there, moving
>> information about required vertex attributes from GPUMaterial to
>> GPUShader, while moving uniform and texture values into a new
>> GPUShaderParams. Nothing radical really.
>>
>> What do you think?
>>
>> Thanks,
>> Brecht.
>> _______________________________________________
>> Bf-viewport mailing list
>> Bf-viewport at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-viewport
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-viewport/attachments/20151205/9b3ea0fc/attachment.htm