<div dir="ltr"><div>Adam, did you notice my original suggestion "If there is at least 1 drm device, swrast won't be in the list."? which means swrast would be in the list for your "dumb" GPUs.<br></div><div><br></div><div>Marek<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 23, 2019 at 7:52 PM Adam Jackson <<a href="mailto:ajax@redhat.com">ajax@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, 2019-04-23 at 19:21 -0400, Marek Olšák wrote:<br>
<br>
> Then I think a separate EGL extension that exposes swrast would be<br>
> better. The thing with the device extensions is that swrast is not a<br>
> device.<br>
<br>
Enh. I've got dumb GPUs I need to support, they need to run OpenGL, and<br>
if they were running swrast-on-otherwise-dumb-gem, I can make posting<br>
the front buffer to the compositor be (at least sometimes) zero-copy,<br>
instead of the XPutImage thing that drisw currently has to do. So I<br>
don't think it's necessarily the case that swrast doesn't have<br>
"hardware" support behind it.<br>
<br>
More generally, if the term in the extension spec was "renderer" not<br>
"device" I don't think we'd be having this discussion. And I think it's<br>
worth having renderer selection be orthogonal in an API sense.<br>
<br>
- ajax<br>
<br>
</blockquote></div>