[ANNOUNCE] xorg-server 1.17.0

Here's the 1.17 release -- just a few patches since the last RC. Thanks to all for making this a really fun release to work on! Adel Gadllah (1): dri2: Set vdpau driver name if ddx does not provide any driver name Dave Airlie (2): randr: attempt to fix primary on slave output (v2)

Re: [PATCH v2] glamor: check max native ALU instructions

Olivier Fourdan ofour...@redhat.com writes: When using glamor (either in Xephyr or Xwayland) on hardware with too low instructions limit, glamor fallbacks to sw due to large shaders. This makes glamor unbearably slow on such hardware. Check reported value for

Re: [PATCH] xwayland: Add dependency on glamor libs

Olivier Fourdan ofour...@redhat.com writes: So that Xwayland gets re-linked each time glamor is modified. Signed-off-by: Olivier Fourdan ofour...@redhat.com Reviewed and merged for -next. signature.asc Description: PGP signature ___

Re: [PATCH 1/3] glamor: Just set the logic op to what we want at the start of all rendering.

Kenneth Graunke kenn...@whitecape.org writes: On Tuesday 30 December 2014 14:54:27 Eric Anholt wrote: By dropping the unconditional logic op disable at the end of rendering, this fixes GL errors being thrown in GLES2 contexts (which don't have logic ops). On desktop, this also means a little

Re: [PATCH v2] ephyr: Fail if glamor is requested but not usable

Olivier Fourdan ofour...@redhat.com writes: Signed-off-by: Olivier Fourdan ofour...@redhat.com Reviewed and picked it up for my -next branch. signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives:

Re: [PATCH 1/3] glamor: Just set the logic op to what we want at the start of all rendering.

Eric Anholt e...@anholt.net writes: By dropping the unconditional logic op disable at the end of rendering, this fixes GL errors being thrown in GLES2 contexts (which don't have logic ops). On desktop, this also means a little less overhead per draw call from taking one less trip through the

Re: [PATCH] glamor: Don't unbind the GL_ARRAY_BUFFER in glamor_put_vbo_space().

Kenneth Graunke kenn...@whitecape.org writes: Mesa's implementation of glBindBuffer() checks to see if the supplied buffer name happens to be already bound. If so, it returns immediately, skipping the hash table lookup (mapping the GLuint buffer handle to the actual struct), the associated

Does the modesetting driver support glamor ?

Hi, I've got the 1.17 server running in qemu - all seemed good, but when I looked at the log I saw (II) glamor: EGL version 1.4 (DRI2): EGL_MESA_drm_image required. (EE) modeset(0): glamor initialization failed and I guess that '(EE)' spooked me into thinking something was wrong. Google

Re: Does the modesetting driver support glamor ?

On 5 February 2015 at 12:08, Ken Moffat zarniwh...@ntlworld.com wrote: Hi, I've got the 1.17 server running in qemu - all seemed good, but when I looked at the log I saw (II) glamor: EGL version 1.4 (DRI2): EGL_MESA_drm_image required. (EE) modeset(0): glamor initialization failed

Re: Does the modesetting driver support glamor ?

On Thu, Feb 05, 2015 at 12:17:42PM +1000, Dave Airlie wrote: On 5 February 2015 at 12:08, Ken Moffat zarniwh...@ntlworld.com wrote: Hi, I've got the 1.17 server running in qemu - all seemed good, but when I looked at the log I saw (II) glamor: EGL version 1.4 (DRI2):

[PATCH 1/3] glamor: Just set the logic op to what we want at the start of all rendering.

By dropping the unconditional logic op disable at the end of rendering, this fixes GL errors being thrown in GLES2 contexts (which don't have logic ops). On desktop, this also means a little less overhead per draw call from taking one less trip through the glEnable/glDisable switch statement of

[PATCH 2/3] glamor: Don't optimize out scissor updates in CopyArea.

This possibly is a minor hit for immediate mode renderers (no difference on copypixin100 on my hsw, n=12), but it gives important information about drawing bounds to a deferred renderer (3.1x improvement in copypixwin100 on vc4). Signed-off-by: Eric Anholt e...@anholt.net ---

[PATCH 3/3] glamor: Add a helper function for the common GL_QUADS fallback pattern.

We should do better than this with an index buffer, but for now at least make it so that we don't have to copy the same code to new places. Signed-off-by: Eric Anholt e...@anholt.net --- glamor/glamor_copy.c | 8 +--- glamor/glamor_rects.c | 9 + glamor/glamor_spans.c | 9

Re: [PATCH 2/3] glamor: Don't optimize out scissor updates in CopyArea.

Eric Anholt e...@anholt.net writes: This possibly is a minor hit for immediate mode renderers (no difference on copypixin100 on my hsw, n=12), but it gives important information about drawing bounds to a deferred renderer (3.1x improvement in copypixwin100 on vc4). If you're going to set the

Re: [PATCH 3/3] glamor: Add a helper function for the common GL_QUADS fallback pattern.

Eric Anholt e...@anholt.net writes: We should do better than this with an index buffer, but for now at least make it so that we don't have to copy the same code to new places. I remember writing the index buffer code at some point; it's really easy as we just need to initialize a static index