<p>I know that it won&#39;t work. I&#39;m interested in how we will make it not work. I will back out some of my doc changes for now, but there are still too many potholes in the spec, and I do not want to unduly delay in fixing them.</p>

<p>Posting from a mobile, pardon my terseness. ~ C.</p>
<p><blockquote type="cite">On Jun 17, 2010 12:05 PM, &quot;Zack Rusin&quot; &lt;<a href="mailto:zackr@vmware.com">zackr@vmware.com</a>&gt; wrote:<br><br><p><font color="#500050">&gt; Considering the disparate ISAs of nvfx, r300, i915, and things we<br>
&gt; don&#39;t have public drivers for ...</font></p>What isn&#39;t such a simple thing?<br>
<p><font color="#500050"><br>&gt; Sure, TGSI has double opcodes. One might think that this is awesome,<br>&gt; and writes a shader using ...</font></p>We don&#39;t provide access to those from anywhere, so that would be very<br>

hard. And when we do it&#39;s going to be in the next generation of state<br>
trackers and these will simply not work with r300g, so as far as I can<br>
tell that can&#39;t happen.<br>
The only scenario here that could make this even remotely possible<br>
is GL and the GL state tracker will need to solve this problem with<br>
caps like it already does. Runtime checking of those things is the<br>
only way it will ever work, docs just don&#39;t solve this problem.<br>
<p><font color="#500050"><br>&gt; Either it asserts (current behavior), or it drops all<br>&gt; the rendering on the floor. We have no wa...</font></p>Yes, that&#39;s not ideal, but that&#39;s a different discussion.<br>

<font color="#888888"><br>
z<br>
</font></blockquote></p>