<div>Hi, </div><div><br><div class="gmail_quote"><div>On Mon, 13 Mar 2017 at 7:08 pm, Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg">On Mon, Mar 13, 2017 at 11:53 AM, Kristian H. Kristensen <span class="gmail_msg"><<a href="mailto:krh@bitplanet.net" class="gmail_msg" target="_blank">krh@bitplanet.net</a>></span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="gmail_msg">Daniel Stone <<a href="mailto:daniel@fooishbar.org" class="gmail_msg" target="_blank">daniel@fooishbar.org</a>> writes:<br></span></blockquote></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="gmail_msg"></span></blockquote></div></div></div><div class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="gmail_msg">
> I guess it depends on how much asymmetry there is between texture and<br class="gmail_msg">
> render formats ... if there isn't much, then we could focus on landing<br class="gmail_msg">
> Varad's work and use that as a jumping-off point. I was under the<br class="gmail_msg">
> impression that there was a pretty big difference for some hardware,<br class="gmail_msg">
> though I guess the GBM implementation would still rank by optimality<br class="gmail_msg">
> when allocating ...<br class="gmail_msg">
<br class="gmail_msg">
</span>Right, but if it's more complicated than what<br class="gmail_msg">
EGL_EXT_image_dma_buf_import_modifiers exposes, do really we want to<br class="gmail_msg">
that logic into gbm?<span class="m_1733709001861654064HOEnZb gmail_msg"><font color="#888888" class="gmail_msg"><br class="gmail_msg"></font></span></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div><div class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg">The GBM API I was thinking of was basically a GBM version of that.  The primary addition to the above extension being some set of usage flags.  There shouldn't be a huge asymmetry between texture and render.  What concerns me more is if you tie some other API into EGL that does media or something (OpenMAX?) you may run into issues where something works for render but not for media decode.  If we don't care about anything other than 3D tying into EGL, then the above API should be ok.<br class="gmail_msg"></div></div></div>
</blockquote></div></div><div>OK, great. Let's just go with that then; I think any more complicated multi-device usecases really fall under the allocator domain, and I'd rather not reinvent that under GBM. </div><div><br></div><div>At the moment, the only users we care about are allocating directly for scanout (so can go through GBM + GetPlane2), or solely for GPU, where EGL modifiers query + GBM allocation is fine.</div><div><br></div><div>Cheers, </div><div>Daniel</div>