On 21/08/17 08:58, Marek Olšák wrote:
On Mon, Aug 21, 2017 at 12:52 AM, Timothy Arceri <tarc...@itsqueeze.com> wrote:
On 21/08/17 03:25, Marek Olšák wrote:

On Thu, Aug 17, 2017 at 1:02 PM, Timothy Arceri <tarc...@itsqueeze.com>
wrote:

Shared (the default) and packed layouts are decided by the
implementation.
Currently we just pack them using the std140 layout. This change makes it
so
we use the slightly more compact std430 layout on i965 and radeonsi.

I doubt this will help many games, but it still seems worth implementing.
I could only find shaders for a single game in my shader-db collection
where STD140 layout wasn't explicitly defined for UBOs, and even there
it was using vec4s so there would be no improvement.


Why having a separate codepath that only 2 drivers will use If it
doesn't improve any app?


I didn't say it doesn't improve any apps, presumably something uses the
shared and packed layout provided by the spec. I just didn't seen it in my
quick search of my shader-db collection.

Ignoring how many apps use it, it's not much of a separate path it mostly
just reuses the existing paths for SSBOs. Also if we can get SNB fixed up
and add support to the remaining Gallium drivers that support ubos than we
can drop the old paths entirely.

All Gallium drivers will never support it (unless you intent to add
support by yourself).


For radeonsi once I get LOAD working with my uniform packing series that
would just leave immediates using the fetch_constant() code path.

What about Nine and VDPAU/VAAPI/OpenMAX also using CONST?

Marek


I wrote the series based on Nicolai's feedback as a way to get more familiar with the LOAD implementation so I could use it with constant packing.

Using LOAD for UBOs was suggested by Nicolai, the Intel guys are interested in enabling this feature. Can you please point out exactly what patches you have concern over and maybe we can focus on that?

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to