glamor_egl: Don't initialize on llvmpipe
Mesa started supporting GL_OES_EGL_image on llvmpipe in 17.3, after this commit: commit bbdeddd5fd0b797e1e281f058338b3da4d98029d Author: Gurchetan Singh <gurchetansingh@chromium.org> Date: Tue Aug 1 14:49:33 2017 -0700 st/dri: add drisw image extension That's pretty cool, but it means glamor now thinks it can initialize on llvmpipe. This is almost certainly not what anyone wants, as glamor on llvmpipe is pretty much uniformly slower than fb. This fixes both Xorg and Xwayland to refuse glamor in such a setup. Xephyr is left alone, both because glamor is not the default there and because Xephyr+glamor+llvmpipe is one of the easier ways to get xts to exercise glamor. The (very small) downside of this change is that you lose DRI3 support. This wouldn't have helped you very much (since an lp glamor blit is slower than a pixman blit), but it would eliminate the PutImage overhead for llvmpipe's glXSwapBuffers. A future change should add DRI3 support for the fb-only case. Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Adam Jackson <ajax@redhat.com>
Loading
-
🎧 @ajaxmentioned in merge request !37 (merged)
-
mentioned in merge request mesa/mesa!15479 (closed)
-
The (very small) downside of this change is that you lose DRI3 support. This wouldn't have helped you very much (since an lp glamor blit is slower than a pixman blit), but it would eliminate the PutImage overhead for llvmpipe's glXSwapBuffers. A future change should add DRI3 support for the fb-only case.
Do you means we need
A future change should add DRI3 support for the fb-only case.
@olv, @ajax How to add DRI3 support for the fb-only case? -
🛠 @ofourdanmentioned in merge request !956 (merged)
-
mentioned in merge request !1033 (merged)
-
mentioned in commit b2b3f67e
Please register or sign in to comment