<div dir="ltr">Hi all,<div><br></div><div>another try to merge android swrast patches in mesa 17.1 or mesa-dev</div><div>if they are somehow considered useful for android.</div><div><br></div><div>Mauro<br><div class="gmail_extra"><br><div class="gmail_quote">2017-01-20 20:17 GMT+01:00 Mauro Rossi <span dir="ltr"><<a href="mailto:issor.oruam@gmail.com" target="_blank">issor.oruam@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"><br><br>Il lunedì 9 gennaio 2017, Zhen Wu <<a>wuzhen@jidemail.com</a>> ha scritto:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Thanks for your review, Rob. Using kms-dri would mean writing a new gralloc to basically the same thing as<br><div>gralloc.default and moving to grm_gralloc seems to be a bigger task meant for another day. But I agree we would</div><div>want to avoid introducing dependency. Would extending drisw loader func and limit gralloc dependency in egl_android<br></div><div>ok with you?</div></div></blockquote><div><br></div></span><div>Just to avoid a stall situation,</div><div><br></div><div>I get that Rob comments are here as here is the gralloc dependency to be avoided.</div><div>Is this assumption correct?</div><div><br></div><div>BTW I can also confirm patches are working as I tested with Android CTS dEQP test for EGL and GLES2 modules with marshmallow-x86</div><span class="gmail-HOEnZb"><font color="#888888"><div><br></div><div>Mauro</div>
</font></span></blockquote></div><br></div><div class="gmail_extra">Hi Rob,</div><div class="gmail_extra">we are still maintaining these changes to use llvmpipe</div><div class="gmail_extra">they are working and they are useful for testing on VMs and for software rendering.</div><div class="gmail_extra"><br></div><div class="gmail_extra">May I kindly jask  if the unwanted gralloc dependency was essentially in  this patch 07/08</div><div class="gmail_extra">"android: support creating texture from gralloc buffer"?</div><div class="gmail_extra"><br></div><div class="gmail_extra">And if that is confirmed, which approaches are applicable here?</div><div class="gmail_extra"><br></div><div class="gmail_extra">1. Reuse some kms-dri specific change implemented in CrOS (? Tomasz did you neeed to change something in dri/sw winsys ? )</div><div class="gmail_extra"><br></div><div class="gmail_extra">2. Look into openswr corresponding code paths (? I don't know if Tapani may provide some info for cross reference)</div><div class="gmail_extra"><br></div><div class="gmail_extra">3. Not touching current <span style="font-size:12.8px"> AS-IS src/gallium/winsys/sw/dri/dri_</span><wbr style="font-size:12.8px"><span style="font-size:12.8px">sw_winsys.c (? was this option mentioned by Emil ?)</span></div><div class="gmail_extra"><span style="font-size:12.8px"><br></span></div><div class="gmail_extra"><span style="font-size:12.8px">4. Rewrite only </span>dri/sw winsys parts with buffer allocation provided by gralloc.gbm (?a kind confirmation by Emil, Rob if this is viable and acceptable)</div><div class="gmail_extra"><br></div><div class="gmail_extra">I think that some kind of retro compatibility/coexistence with gralloc.drm<br></div><div class="gmail_extra">is desirable, so I wanted to kindly ask for you feedbacks</div><div class="gmail_extra">and as usual I'm available for building/testing and also to try to patch some code</div></div><div class="gmail_extra">to have it working, acceptable and merged.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Mauro</div></div>