<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 11, 2015 at 5:13 PM, Kenneth Graunke <span dir="ltr"><<a href="mailto:kenneth@whitecape.org" target="_blank">kenneth@whitecape.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wednesday, March 11, 2015 03:33:24 PM Jason Ekstrand wrote:<br>
> I'm not terribly happy with how this worked out, I'm not going to NAK it as<br>
> I think it's the best we can do at the moment.<br>
><br>
> The reason why Connor (and others) have chosen to emit these things at the<br>
> top of the shader is because they frequently require some computation and<br>
> we don't want to duplicate that if we don't have to.  However, it also<br>
> leads to variables with very long live ranges which we don't want either.<br>
> Once we have GVN, we can value-number system value intrinsics.  This will<br>
> ensure that we only do the (potentially expensive) caluculation once and<br>
> GCM will ensure that they land as far down the program as we can put them.<br>
> However, until we have GVN, this seems like as good as we're going to get<br>
> at the moment.<br>
> --Jason<br>
<br>
</span>I think this code is fine.<br>
<br>
The built-in variables handled here are gl_VertexID and gl_InstanceID.<br>
Here, gl_VertexID = gl_VertexIDMESA (0-based) + gl_BaseVertex.<br>
<br>
All three values show up as an incoming vec4 vertex attribute, supplied<br>
by the vertex fetcher like any other vertex data.  This means that they<br>
inherently occupy registers starting at the beginning of the program.<br>
<br>
The only computation we could delay is the ADD for gl_VertexID.<br>
However, in SIMD8 VS, it appears that gl_VertexIDMESA and gl_BaseVertex<br>
occupy separate registers.  So doing the ADD up front actually makes 2<br>
GRFs available, at the cost of 1 GRF.  It's actually better up front.<br>
<br>
For the FS system values - gl_SampleID and the like - you have a point.<br>
The inputs to the calculation tend to come from g0/g1, which usually<br>
live for the whole shader anyway.  So we can compute the value whenever<br>
we like - moving it closer to the use would reduce live ranges, and<br>
potentially put it inside control flow, so it might be skipped<br>
altogether on some invocations.<br>
<br>
That's just not the case for the VS system values.<br>
</blockquote></div><br></div><div class="gmail_extra">Sure, and I'm not picky about where the math happens.  I just don't like this two-step emit process where we put a bunch of stuff at the top of the shader and then mov's down below.  I'd rather we just put the system value intrinsic at the top where we want it and emit it when we hit it in the emit pass.  I'm not super-picky about it but that just seems to make mores sense to me.<br></div><div class="gmail_extra">--Jason<br></div></div>