<div dir="ltr"><div><div><div>Hi Brecht,<br><br></div>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. <br>Anthony's comment "<i>..., and we have
a use-case-specific shader interface which sits on top of it.</i>" 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.<br></div>I think the possible Vulkan backend could maybe be further detailed with help of someone with access to the specs.<br><br></div><div>thx again for the writeup.<br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Dec 5, 2015 at 10:55 AM, Antony Riakiotakis <span dir="ltr"><<a href="mailto:kalast@gmail.com" target="_blank">kalast@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Just a side note here:<br><br></div>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.<br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On 5 December 2015 at 10:50, Antony Riakiotakis <span dir="ltr"><<a href="mailto:kalast@gmail.com" target="_blank">kalast@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi Brecht, thanks for the work!<br><br>A few improvements, if I may:<br><br></div><div>* Transform is no different than a GPUShaderParam now. One can easily think of UI shaders where we just work with 2D coordinates<br><br></div><div>* 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 :) ).<br><br></div><div>* Passing all parameters to the shader like that:<br><br><pre>draw<span>(</span>shader, params, vertex_buffers, transformation<span>)</span><span>;</span></pre>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.<br><br></div><div>This can be achieved with a two layer system:<br></div><div>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.<br><br></div><div>So the whole workflow looks something like that:<br><br><br></div><div>1) compile shader<br></div><div>2) client code obtains input slots (attributes, textures, uniforms) from a use-case specific interface.<br></div><div>For instance, for a lighted mesh, client code can request a specific "light" struct from the inteface.<br></div><div>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.<br></div><div>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.<br></div><div>3) Interface objects can be cached and reused.<br></div><div>4) draw call sequence is now:<br></div><div><br>----------------------<br></div><div>shader->compile()<br><br></div><div>/* gets relevant indices for attributes, uniform blocks etc, needs to happen just once after shader compilation */<br></div><div>interface->aqcuireFromShader(shader);<br><br></div><div>LightParams *lp = interface->getLightParams();<br></div><div><br></div><div>lp->light_pos = pos;<br></div><div><br></div><div><div>GPUAttribute *p = interface->getPositionAttribute();<br></div><br>GPU_bind_vertex_buffer(p, offset, stride, etc...);<br><br>GPUAttribute *n = interface->getNormalAttribute();<br><br></div><div>GPU_constant_attrib(n, value);<br></div><div><br>/* keep interface for later use, do more stuff */<br>...<br><br><div>/* bind shader */<br></div><div>shader->bind();<br></div><br></div><div>/* sets attributes appropriately and effectively */<br></div><div>interface->bind();<br><br></div><div>/* draw */<br></div><div>GPUdraw(numeElements, drawType)<br></div><div>-----------------------------<br><br></div><div>This decouples the low level stuff from the client code stuff quite effectively imo.<br><br></div><div>* 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.<br><br></div><div>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).<br><br></div><div>I think that's all my input for now.<br></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On 5 December 2015 at 03:02, Brecht Van Lommel <span dir="ltr"><<a href="mailto:brechtvanlommel@gmail.com" target="_blank">brechtvanlommel@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
I've written a rough proposal for the low level shader API that all<br>
OpenGL shaders would use, both for mesh and UI drawing.<br>
<a href="http://wiki.blender.org/index.php/Dev:2.8/Source/OpenGL/Shaders" rel="noreferrer" target="_blank">http://wiki.blender.org/index.php/Dev:2.8/Source/OpenGL/Shaders</a><br>
<br>
It builds on data structures and APIs that are already there, moving<br>
information about required vertex attributes from GPUMaterial to<br>
GPUShader, while moving uniform and texture values into a new<br>
GPUShaderParams. Nothing radical really.<br>
<br>
What do you think?<br>
<br>
Thanks,<br>
Brecht.<br>
_______________________________________________<br>
Bf-viewport mailing list<br>
<a href="mailto:Bf-viewport@blender.org" target="_blank">Bf-viewport@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-viewport" rel="noreferrer" target="_blank">http://lists.blender.org/mailman/listinfo/bf-viewport</a><br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Bf-viewport mailing list<br>
<a href="mailto:Bf-viewport@blender.org">Bf-viewport@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-viewport" rel="noreferrer" target="_blank">http://lists.blender.org/mailman/listinfo/bf-viewport</a><br>
<br></blockquote></div><br></div>