<p>I know that it won't work. I'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, "Zack Rusin" <<a href="mailto:zackr@vmware.com">zackr@vmware.com</a>> wrote:<br><br><p><font color="#500050">> Considering the disparate ISAs of nvfx, r300, i915, and things we<br>
> don't have public drivers for ...</font></p>What isn't such a simple thing?<br>
<p><font color="#500050"><br>> Sure, TGSI has double opcodes. One might think that this is awesome,<br>> and writes a shader using ...</font></p>We don't provide access to those from anywhere, so that would be very<br>
hard. And when we do it'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'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't solve this problem.<br>
<p><font color="#500050"><br>> Either it asserts (current behavior), or it drops all<br>> the rendering on the floor. We have no wa...</font></p>Yes, that's not ideal, but that's a different discussion.<br>
<font color="#888888"><br>
z<br>
</font></blockquote></p>