<div dir="ltr">Alright it's clear now, thanks for the detailed answer.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 5 December 2015 at 20:10, Brecht Van Lommel <span dir="ltr"><<a href="mailto:brechtvanlommel@pandora.be" target="_blank">brechtvanlommel@pandora.be</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've updated the proposal now with GPUShaderInstance and more example code:<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>
<span class=""><br>
On Sat, Dec 5, 2015 at 6:18 PM, Antony Riakiotakis <<a href="mailto:kalast@gmail.com">kalast@gmail.com</a>> wrote:<br>
> Every time the relevant data changes. Light position was a bad example of<br>
> that, let's say transform is a better example here. I don't think we need<br>
> data to be immutable on the GPU, just cached.<br>
><br>
> Keep in mind that when rebinding a shader, we are required to rebind all the<br>
> uniform state. This is not as bad with uniform buffer objects but for GL 2.1<br>
> it makes sense to have a way to bind all data.<br>
<br>
</span>Looking towards Vulkan, imagine if you draw once with one set of<br>
uniform values, and another time with other uniform values. Then you<br>
need to allocate two buffers with uniforms, and keep those around<br>
until the command buffer has finished rendering. You can't just have a<br>
single buffer and modify that because it would affect both draw<br>
operations.<br>
<br>
If you make these things mutable, then every time you change the data<br>
we (or the OpenGL driver) need to make a copy of the data to avoid<br>
that kind of interference. I rather avoid doing that under the hood,<br>
it's one of the sources of inefficiency in the OpenGL API design. If<br>
we make things immutable we avoid that problem, and it will make<br>
multithreading easier as well.<br>
<br>
As I understand it, you can prepare the next frame on the CPU while<br>
the previous frame is still drawing on the GPU, for efficiency those<br>
computations can overlap. This means that under the hood your data has<br>
to be effectively immutable on the GPU anyway, otherwise rendering the<br>
two frames will interfere.<br>
<br>
For sorting it's also easy if you can just compare pointers instead of<br>
the actual state.<br>
<br>
Regards,<br>
Brecht.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<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>
</div></div></blockquote></div><br></div>