<div dir="ltr">On 20 August 2013 14:04, Kenneth Graunke <span dir="ltr"><<a href="mailto:kenneth@whitecape.org" target="_blank">kenneth@whitecape.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 08/20/2013 11:30 AM, Paul Berry wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Previously, we would always use the same push constant allocation<br>
regardless of what shader programs were being run: the available push<br>
constant space was split into 2 equal size partitions, one for the<br>
vertex shader, and one for the fragment shader.<br>
<br>
Now that we are adding geometry shader support, we need to do<br>
something smarter.  This patch adjusts things so that when a geometry<br>
shader is in use, we split the available push constant space into 3<br>
nearly-equal size partitions instead of 2.<br>
<br>
Since the push constant allocation is now affected by GL state, it can<br>
no longer be set up by brw_upload_initial_gpu_state()<u></u>; instead it must<br>
be set up by a state atom.<br>
</blockquote>
<br></div>
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?<br>
<br>
--Ken<br>
</blockquote></div><br></div><div class="gmail_extra">I considered this while writing the patch series.  Briefly, here was my thinking:<br><br></div><div class="gmail_extra">Arguments in favor of a fixed 33/33/33 allocation of space all the time:<br>
<br></div><div class="gmail_extra">- 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.<br>
<br></div><div class="gmail_extra">- No change in the ordering of commands we send to the GPU (which also leads to less risk of GPU hangs).<br><br></div><div class="gmail_extra">Arguments in favor of changing the allocation dynamically:<br>
<br></div><div class="gmail_extra">- 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.<br>
<br></div><div class="gmail_extra">- 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.<br>
<br></div><div class="gmail_extra"><br>IMHO, it's a close call, but the arguments in favor of dynamic allocation are stronger.</div></div>