[Bf-viewport] OpenGL low level shader API proposal

[Antony Riakiotakis]

Alright it's clear now, thanks for the detailed answer.

On 5 December 2015 at 20:10, Brecht Van Lommel <brechtvanlommel at pandora.be>
wrote:

> I've updated the proposal now with GPUShaderInstance and more example code:
> http://wiki.blender.org/index.php/Dev:2.8/Source/OpenGL/Shaders
>
> On Sat, Dec 5, 2015 at 6:18 PM, Antony Riakiotakis <kalast at gmail.com>
> wrote:
> > 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.
>
> Looking towards Vulkan, imagine if you draw once with one set of
> uniform values, and another time with other uniform values. Then you
> need to allocate two buffers with uniforms, and keep those around
> until the command buffer has finished rendering. You can't just have a
> single buffer and modify that because it would affect both draw
> operations.
>
> If you make these things mutable, then every time you change the data
> we (or the OpenGL driver) need to make a copy of the data to avoid
> that kind of interference. I rather avoid doing that under the hood,
> it's one of the sources of inefficiency in the OpenGL API design. If
> we make things immutable we avoid that problem, and it will make
> multithreading easier as well.
>
> As I understand it, you can prepare the next frame on the CPU while
> the previous frame is still drawing on the GPU, for efficiency those
> computations can overlap. This means that under the hood your data has
> to be effectively immutable on the GPU anyway, otherwise rendering the
> two frames will interfere.
>
> For sorting it's also easy if you can just compare pointers instead of
> the actual state.
>
> Regards,
> 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/95638729/attachment.htm