<div dir="ltr">On 8 September 2013 19:49, 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 09/08/2013 08:48 AM, Paul Berry wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On 4 September 2013 15:22, Kenneth Graunke <<a href="mailto:kenneth@whitecape.org" target="_blank">kenneth@whitecape.org</a><br></div><div class="im">
<mailto:<a href="mailto:kenneth@whitecape.org" target="_blank">kenneth@whitecape.org</a>><u></u>> wrote:<br>
<br>
    During compilation, we'll use this to determine built-in availability.<br>
    All the prototypes will be available, but we can filter out the ones<br>
    that aren't actually available.<br>
<br>
<br>
I'm having trouble understanding this sentence because it sounds like<br>
you're using the word "available" to mean two different things.  Do you<br>
perhaps mean something like "when looking up the name of a built-in<br>
function, we'll iterate through a list of all the prototypes that exist<br>
in all GLSL versions and extensions, but we'll filter out the ones that<br>
aren't actually available in the current GLSL version with the currently<br>
enabled extensions"?<br>
</div></blockquote>
<br>
Poor wording on my part; your understanding is basically correct.<br>
<br>
I've replaced it with this text:<br>
"The plan is to have a single shader containing every built-in in every<br>
version of the language, but filter out the ones that aren't actually<br>
available to the shader being compiled."<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
    At link time, we don't actually need this filtering capability, since<br>
    we've already imported the prototypes and flagged them as "is_builtin."<br>
<br>
<br>
This sentence tripped me up a bit since the last patch removed the<br>
"is_builtin" flag in favor of a function.  Do you mean to say that we've<br>
already imported the prototypes and given them a non-null builtin_info<br>
(so is_builtin() will return true)?<br>
</blockquote>
<br></div>
By "is_builtin flag" I meant "the value of the is_builtin() method."<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
    The linker won't import additional prototypes, so it won't pull in any<br>
    unavailable built-ins.  Conversely, the is_builtin flag will prevent a<br>
    shader from defining its own prototype and fooling the linker to import<br>
    a built-in's body.<br>
<br>
<br>
Similarly, in this case do you mean "conversely, prototypes defined by<br>
the shader will have builtin_info = null, so they will return false for<br>
is_builtin() and that will prevent the linker from trying to import a<br>
built-in's body for those functions"?<br>
<br>
      All that to say: we can just pass in NULL.  It'll be<br>
    fine.<br>
</blockquote>
<br></div>
Yes.  I've replaced this text with:<br>
<br>
"At link time, we don't actually need this filtering capability: we've<br>
already imported prototypes for every built-in that the shader actually<br>
calls, and they're flagged as is_builtin().  The linker doesn't import<br>
any additional prototypes, so it won't pull in any unavailable<br>
built-ins.  When resolving prototypes to function definitions, the<br>
linker ensures the values of is_builtin() match, which means that a<br>
shader can't trick the linker into importing the body of an unavailable<br>
built-in by defining a suspiciously similar prototype.<br>
<br>
In other words, during linking, we can just pass in NULL.  It will work<br>
out fine."<br>
</blockquote></div><br></div><div class="gmail_extra">Ok, that makes sense.  Thanks for the clarification.<br></div></div>