<div dir="ltr">Hi Matt,<br><br>On Wed, Apr 17, 2013 at 12:58 AM, Matt Turner <span dir="ltr"><<a href="mailto:mattst88@gmail.com" target="_blank">mattst88@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>On Tue, Apr 16, 2013 at 9:45 AM, Chia-I Wu <<a href="mailto:olvaffe@gmail.com" target="_blank">olvaffe@gmail.com</a>> wrote:<br>


> If there is no objection, I'd like to merge it in a day or two.<br>
<br>
</div>My only objection is over adding a driver that is explicitly a toy,<br>
the confusion it will cause users, and the developer time it will<br>
waste. It wasn't uncommon for a user to waste a nontrivial amount of<br>
someone's time in #intel-gfx only to discover that they were trying to<br>
use the (old) i965g driver that no one maintained.<br></blockquote><div>I think there are two concerns here: the driver is a toy and the driver can be confusing.  And I agree with both.<br><br></div><div>But being a toy has its advantages.  For example, if someone sends me a patch to incorporate beignet backend and hook the driver up with clover OpenCL state tracker, I will be happy to take the patch.  It might have loose ends or known issues, but as long as the developer is committed to fix them, they will be resolved over time.  Same if someone wants to work on video decoding and etc.<br>
<br></div><div>While being a toy, the driver is developed seriously and is always kept in a usable state.  This is mainly thanks to piglit, to which your team contribute a lot.  After making changes, I run piglit to make sure there is no regression.  I even have a spreadsheet documenting why each of the current 429 failures fails.  There were like ~650 failures last December.  I've fixed quite some, and I plan to keep going.  That is why I haven't started looking at the performance.<br>

</div><div><br></div><div>As you can see, I have to reorganize the commits to have a clean history before attempting to merge it to master.  If I had to wait until the driver is no longer a toy to merge it, it would lose more of its history by the time it is finally merged.<br>
</div><div><br></div><div>I started the driver because I wanted to play with gallium and I did not have any radeon/nvidia card.  There could be other potential developers who are in the same situation.  I believe having the driver in master allows them to get started more easily.<br>
</div><div><br></div><div>If you could agree with me, then, technically, we need to make the new driver less confusing.  The driver is disabled by default, of course.  It can be enabled with --with-gallium-drivers=i965 now.  Would it help if I change it to something like --enable-gallium-drivers=i965-UNOFFICIAL?  Or do you have any suggestion, given your experiences dealing with i915g or the old i965g bug reports?<br>
<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I think everything Marek said was correct. If you could extend Gallium<br>
to consume GLSL IR it might actually be an interesting project.<br></blockquote><div>Yes, it is.  I do want to make pipe drivers be able to express the preferred IR and make the mesa state tracker generate it.  I had LLVM IR in mind, but GLSL IR could be a much less intrusive choice.  I will check that out.<br>
</div></div></div><div class="gmail_extra"><br>-- <br>olv@LunarG.com
</div></div>