[Bf-viewport] OpenGL low level shader API proposal

[Martijn Berger]

Hi Brecht,

I really like the design and think it could bring us to running in a core
context (or ES 2.0 + ) and on-top of Vulkan.
Anthony's comment "*..., and we have a use-case-specific shader interface
which sits on top of it.*" Is something where I think most people ( i mean
coders here ) would be really interested in to see what those could look
like. Implementing and using these is what a lot of the refactoring work
will come to in practice.
I think the possible Vulkan backend could maybe be further detailed with
help of someone with access to the specs.

thx again for the writeup.


On Sat, Dec 5, 2015 at 10:55 AM, Antony Riakiotakis <kalast at gmail.com>
wrote:

> 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
>>>
>>
>>
>
> _______________________________________________
> 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/cce47a42/attachment.htm