[Mesa-dev] Rework uniform storage

[Ian Romanick]

On 04/13/2016 03:23 PM, Jakob Sinclair wrote:
> Hi! This idea was first suggested by Tim Arceri and it's about how mesa
> handles uniform storage.
> 
> If you look at the struct gl_uniform_storage you will notice that we
> have two variables here that stores the data:
> 
>     unsigned num_driver_storage;
>     struct gl_uniform_driver_storage *driver_storage;
> 
> But we also have another one:
> 
>     gl_constant_value *storage
> 
> This is maybe not very efficient because we basicly have to store the
> same data twice. It also makes the code more confusing to work with
> because there are more interfaces to think about when implementing a
> driver.
> 
> The reason behind why we have both of these solutions are, as far as I
> know, because almost all the drivers use the driver_storage interface.
> That is probably due to a historical reason, please correct if I'm wrong.
> Meanwhile gl_constant_value is used for glGetUniform and the
> i965 driver. Reworking the uniform storage so it just uses the
> gl_constant_value could lead to much simplier, but also more effiecient,
> code.

You are correct about gl_constant_value being used for glGetUniform.

The idea behind driver_storage was that drivers could pick a layout for
uniform data, have the common code store it in that layout, then
directly upload that blob to the batch for submission.

When I created this system, there was a lot of variation among various
hardware backends.  Some hardware wanted everything as floats
(regardless of the real type).  Some hardware wanted Boolean values as
{0, 1} and some wanted {0, ~0}.  The Boolean variation is largely gone,
and, by and large, people don't care so much about old, float-centric
hardware any more.

As result, most of the code is for dealing with storing to
driver_storage in the representation that the hardware wants.  If we
ignore float-centric hardware, pretty much all of that code is useless
and has no reason to keep living.

I think there is still a place for a system similar to to
driver_storage, but I'm not sure what it would look like.  I talked a
bit with Ken, Matt, and Jason, and we had some ideas for
experimentation... but nothing concrete.

> So is it a reasonable idea to implement right now?
> What kind of problems could you expect and would anyone benefit from
> it?