[Mesa-dev] [PATCH 27/30] i965/gs: Allocate push constant space.

[Paul Berry]

On 20 August 2013 14:04, Kenneth Graunke <kenneth at whitecape.org> wrote:

> On 08/20/2013 11:30 AM, Paul Berry wrote:
>
>> Previously, we would always use the same push constant allocation
>> regardless of what shader programs were being run: the available push
>> constant space was split into 2 equal size partitions, one for the
>> vertex shader, and one for the fragment shader.
>>
>> Now that we are adding geometry shader support, we need to do
>> something smarter.  This patch adjusts things so that when a geometry
>> shader is in use, we split the available push constant space into 3
>> nearly-equal size partitions instead of 2.
>>
>> Since the push constant allocation is now affected by GL state, it can
>> no longer be set up by brw_upload_initial_gpu_state()**; instead it must
>> be set up by a state atom.
>>
>
> I've actually never seen any performance change from increasing or
> decreasing the size of this area.  What do you think about just allocating
> VS, GS, and PS space all the time?
>
> --Ken
>

I considered this while writing the patch series.  Briefly, here was my
thinking:

Arguments in favor of a fixed 33/33/33 allocation of space all the time:

- Less complex (which means less risk of correctness bugs, crashes, or GPU
hangs).  Although in fairness this code is not terribly complex compared to
the rest of the driver, and most of the risk is confined to programs that
use geometry shaders.

- No change in the ordering of commands we send to the GPU (which also
leads to less risk of GPU hangs).

Arguments in favor of changing the allocation dynamically:

- Less risk of performance regressions on existing benchmarks (those that
don't use geometry shaders), since it means we will be using exactly the
same 50/50 push constant allocation in those benchmarks that we were using
before.

- More forward-looking.  In the not-too-distant future we are going to have
to add tessellation control and tessellation evaluation shaders to the
mix.  It will be fairly trivial to extend this dynamic algorithm to support
those additional pipeline stages.  Whereas if we do a fixed 33/33/33
allocation now, then in the future we'll want to change that to
20/20/20/20/20, and that will carry even more risk of performance
regressions.


IMHO, it's a close call, but the arguments in favor of dynamic allocation
are stronger.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130821/63c991cf/attachment-0001.html>