Re: [PATCH 7/8] glamor: add core profile support to EGL glamor. (v2)

[Michel Dänzer]

On 19.01.2016 16:02, Dave Airlie wrote:
> From: Dave Airlie 
> 
> This breaks ABI unfortunately as we have to pass the core profile
> info from the egl part of glamor to the glamor part of glamor.

Drop this paragraph.


> @@ -798,12 +807,21 @@ glamor_egl_init(ScrnInfoPtr scrn, int fd)
>  KHR_surfaceless_opengl);
>  #endif
>  
> +#ifndef GLAMOR_GLES2
>  glamor_egl->context = eglCreateContext(glamor_egl->display,
> NULL, EGL_NO_CONTEXT,
> -   config_attribs);
> -if (glamor_egl->context == EGL_NO_CONTEXT) {
> -xf86DrvMsg(scrn->scrnIndex, X_ERROR, "Failed to create EGL 
> context\n");

Might be nice to keep something like

if (glamor_egl->context == EGL_NO_CONTEXT) {
   xf86DrvMsgVerb(scrn->scrnIndex, X_WARNING, 4,
  "Failed to create EGL OpenGL core profile context\n");
}


> -goto error;
> +   config_attribs_core);
> +#else
> +glamor_egl->context = NULL;

s/NULL/EGL_NO_CONTEXT/ ?


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: glamor core profile support

[Marek Olšák]

On Tue, Jan 19, 2016 at 1:56 AM, Dave Airlie  wrote:
> This series implements support for glamor in ephyr/EGL/Xwayland
> to use GL core profile when it can.
>
> This required 4 main changes:
> a) stop using client ptrs everywhere, I found 3 places left,
> gradient, picture and xv where we use these.
> b) start using VAOs
> c) use GL_RED instead of GL_ALPHA
> d) stop using GL_QUADS.

Won't this negatively affect performance on drivers which can do quads natively?

Marek
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH v2 xserver] glamor: Disable debugging messages other than GL API errors

[Eric Anholt]

Michel Dänzer  writes:

> From: Michel Dänzer 
>
> According to Nicolai Hähnle, the relevant specification says "All
> messages are initially enabled unless their assigned severity is
> DEBUG_SEVERITY_LOW", so we need to explicitly disable the messages we
> don't want to get. Failing that, we were accidentally logging e.g.
> shader stats intended for shader-db.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93659
> Tested-by: Laurent Carlier 
> Reviewed-by: Emil Velikov 
> Signed-off-by: Michel Dänzer 
> ---
>
> v2: Added Bugzilla/Tested-by/Reviewed-by tags

Merged:

commit 1db6de7b6a6ee240eb50a13fe1fa1e135d7cb93b
Author: Michel Dänzer 
Date:   Tue Jan 12 15:42:47 2016 +0900

glamor: Disable debugging messages other than GL API errors


signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] glamor: don't do copy if we have 0 boxes to copy.

[Dave Airlie]

On 20 January 2016 at 03:56, Eric Anholt  wrote:
> Dave Airlie  writes:
>
>> From: Dave Airlie 
>>
>> This happens if you run twm + mplayer + xclock and drag
>> the clock over the mplayer. If we don't catch it, we cause
>> an illegal draw elements command to be passed to GL.
>
> What exactly is the error?  I was thinking it would be something about
> count == 0, but that's not an error apparently.  If there is one about
> count == 0, shouldn't we just have
> glamor_gldrawarrays_quads_using_indices() do the short circuit so the
> callers don't have to worry about it?

Why do all the lowlevel work when we can catch it before then?

essentially glamor_priv->ib_size is 0, and count is 0, so we don't set
up an IB., then we call glDrawElements without a bound IB, and it
gets upset.

Dave.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] glamor: don't do copy if we have 0 boxes to copy.

[Eric Anholt]

Dave Airlie  writes:

> From: Dave Airlie 
>
> This happens if you run twm + mplayer + xclock and drag
> the clock over the mplayer. If we don't catch it, we cause
> an illegal draw elements command to be passed to GL.

What exactly is the error?  I was thinking it would be something about
count == 0, but that's not an error apparently.  If there is one about
count == 0, shouldn't we just have
glamor_gldrawarrays_quads_using_indices() do the short circuit so the
callers don't have to worry about it?


signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH evdev 2/2] Don't reset the other axis on wheel emulation scroll buildup

[Peter Hutterer]

The idea was that of a direction lock: as we move vertically we should not
build up any horizontal scroll motion even if we move slightly diagonally.

The effect was though that the axis would be reset completely as soon as an
event from the other axis occured. With the default threshold of 10, if one in
ten events was a REL_X, we'd never get a wheel event.

Drop this code, it's not needed. By default wheel emulation doesn't do
horizontal scrolling, if a config snippet sets XAxisMapping the user wants
horizontal scrolling. And since we just add the value anyway, as long as the
user does a roughly vertical motion we won't get over the threshold anyway.

https://bugs.freedesktop.org/show_bug.cgi?id=93617

Signed-off-by: Peter Hutterer 
---
 src/emuWheel.c | 13 +++--
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/src/emuWheel.c b/src/emuWheel.c
index f1d1990..c82c240 100644
--- a/src/emuWheel.c
+++ b/src/emuWheel.c
@@ -95,7 +95,7 @@ BOOL
 EvdevWheelEmuFilterMotion(InputInfoPtr pInfo, struct input_event *pEv)
 {
 EvdevPtr pEvdev = (EvdevPtr)pInfo->private;
-WheelAxisPtr pAxis = NULL, pOtherAxis = NULL;
+WheelAxisPtr pAxis = NULL;
 int value = pEv->value;
 
 /* Has wheel emulation been configured to be enabled? */
@@ -130,13 +130,11 @@ EvdevWheelEmuFilterMotion(InputInfoPtr pInfo, struct 
input_event *pEv)
/* ABS_X has the same value as REL_X, so this case catches both */
case REL_X:
pAxis = &(pEvdev->emulateWheel.X);
-   pOtherAxis = &(pEvdev->emulateWheel.Y);
break;
 
/* ABS_Y has the same value as REL_Y, so this case catches both */
case REL_Y:
pAxis = &(pEvdev->emulateWheel.Y);
-   pOtherAxis = &(pEvdev->emulateWheel.X);
break;
 
default:
@@ -144,15 +142,10 @@ EvdevWheelEmuFilterMotion(InputInfoPtr pInfo, struct 
input_event *pEv)
}
 
/* If we found REL_X, REL_Y, ABS_X or ABS_Y then emulate a mouse
-  wheel.  Reset the inertia of the other axis when a scroll event
-  was sent to avoid the buildup of erroneous scroll events if the
-  user doesn't move in a perfectly straight line.
+  wheel.
 */
if (pAxis)
-   {
-   if (EvdevWheelEmuInertia(pInfo, pAxis, value))
-   pOtherAxis->traveled_distance = 0;
-   }
+   EvdevWheelEmuInertia(pInfo, pAxis, value);
 
/* Eat motion events while emulateWheel button pressed. */
return TRUE;
-- 
2.5.0

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH 3/8] glamor: Use vertex arrays

[Eric Anholt]

Dave Airlie  writes:

> From: Keith Packard 
>
> Core contexts require the use of vertex arrays, so switch both glamor
> and ephyr/glamor over.
>
> Signed-off-by: Keith Packard 
> Signed-off-by: Dave Airlie 

commit message should s/vertex arrays/vertex array objects/.  With that
changed, patches other than the GL_RED one are:

Reviewed-by: Eric Anholt 

I think GL_RED's going to have rendering bugs, and I'm doing a
piglit-xts run now to check.


signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH evdev 1/2] Restore wheel emulation for absolute devices

[Peter Hutterer]

Wheel emulation relies on oldVals, which stopped updating in 3dcf6f123c5.

Since wheel emulation may filter the abs event, store the event before we do
anything with it. If we really want the abs_event, abs_queued will be set to
1, otherwise the value will be ignored.

And now that we know abs_value is always valied, we can copy its value into
old_vals, so that wheel emulation can calculate the delta correctly.

https://bugs.freedesktop.org/show_bug.cgi?id=93617

Signed-off-by: Peter Hutterer 
---
 src/evdev.c | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/src/evdev.c b/src/evdev.c
index 3176660..0fcb0bb 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -430,6 +430,14 @@ static void
 EvdevProcessValuators(InputInfoPtr pInfo)
 {
 EvdevPtr pEvdev = pInfo->private;
+int val;
+
+if (pEvdev->abs_vals) {
+if (valuator_mask_fetch(pEvdev->abs_vals, 0, ))
+valuator_mask_set(pEvdev->old_vals, 0, val);
+if (valuator_mask_fetch(pEvdev->abs_vals, 1, ))
+valuator_mask_set(pEvdev->old_vals, 1, val);
+}
 
 /* Apply transformations on relative coordinates */
 if (pEvdev->rel_queued) {
@@ -765,6 +773,12 @@ EvdevProcessAbsoluteMotionEvent(InputInfoPtr pInfo, struct 
input_event *ev)
 if (ev->code > ABS_MAX)
 return;
 
+/* Always store the current abs valuator, we need it to update old_vals
+ * which is required by wheel emulation */
+map = pEvdev->abs_axis_map[ev->code];
+if (map < 2)
+valuator_mask_set(pEvdev->abs_vals, map, value);
+
 if (EvdevWheelEmuFilterMotion(pInfo, ev))
 return;
 
@@ -781,10 +795,7 @@ EvdevProcessAbsoluteMotionEvent(InputInfoPtr pInfo, struct 
input_event *ev)
 valuator_mask_set(pEvdev->rel_vals, map, value - oldval);
 pEvdev->rel_queued = 1;
 }
-valuator_mask_set(pEvdev->old_vals, map, value);
 } else {
-/* the normal case: just store the number. */
-valuator_mask_set(pEvdev->abs_vals, map, value);
 pEvdev->abs_queued = 1;
 }
 }
-- 
2.5.0

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH 6/8] ephyr: Create 3.3 core profile context if possible (v3)

[Matt Turner]

On Mon, Jan 18, 2016 at 11:02 PM, Dave Airlie  wrote:
> From: Keith Packard 
>
> On desktop GL, Ask for a 3.3 core profile context if that's available,
> otherwise create a generic context.
>
> v2: tell glamor the profile is a core one.
> v2.1: add/use GL version defines
> v3: let glamor work out core itself
>
> Signed-off-by: Keith Packard 
> Signed-off-by: Dave Airlie 
> ---
>  hw/kdrive/ephyr/ephyr_glamor_glx.c | 18 +-
>  1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/hw/kdrive/ephyr/ephyr_glamor_glx.c 
> b/hw/kdrive/ephyr/ephyr_glamor_glx.c
> index 30c5245..b9fe8d1 100644
> --- a/hw/kdrive/ephyr/ephyr_glamor_glx.c
> +++ b/hw/kdrive/ephyr/ephyr_glamor_glx.c
> @@ -41,6 +41,10 @@
>  #include "os.h"
>  #include 
>
> +/* until we need geometry shaders GL3.1 should suffice. */
> +/* Xephyr has it's own copy of this for build reasons */
> +#define GLAMOR_GL_CORE_VER_MAJOR 3
> +#define GLAMOR_GL_CORE_VER_MINOR 1
>  /** @{
>   *
>   * global state for Xephyr with glamor.
> @@ -319,7 +323,19 @@ ephyr_glamor_glx_screen_init(xcb_window_t win)
> "GLX_EXT_create_context_es2_profile\n");
>  }
>  } else {
> -ctx = glXCreateContext(dpy, visual_info, NULL, True);
> +static const int context_attribs[] = {
> +GLX_CONTEXT_PROFILE_MASK_ARB,
> +GLX_CONTEXT_CORE_PROFILE_BIT_ARB,
> +GLX_CONTEXT_MAJOR_VERSION_ARB,
> +GLAMOR_GL_CORE_VER_MAJOR,
> +GLX_CONTEXT_MINOR_VERSION_ARB,
> +GLAMOR_GL_CORE_VER_MINOR,
> +0,
> +};
> +ctx = glXCreateContextAttribsARB(dpy, fb_config, NULL, True,
> + context_attribs);
> +if (!ctx)
> +ctx = glXCreateContext(dpy, visual_info, NULL, True);
>  }
>  if (ctx == NULL)
>  FatalError("glXCreateContext failed\n");
> --

GL 3.2 adds profiles -- they're not available in GL 3.1. The
GLX_ARB_create_context_profile spec says:

 If the requested OpenGL version is less than 3.2,
 GLX_CONTEXT_PROFILE_MASK_ARB is ignored and the functionality
 of the context is determined solely by the requested version.


If you simply ask for 3.1, you may get GL_ARB_compatibility... The spec says:

If version 3.1 is requested, the context returned may implement
any of the following versions:

  * Version 3.1. The GL_ARB_compatibility extension may or may not
be implemented, as determined by the implementation.
  * The core profile of version 3.2 or greater.

It's probably a safe bet that no driver we care about glamor running
on will implement GL_ARB_compatibility, so maybe asking for 3.1 is the
best thing to do. The lack of profiles in 3.1 is a real pain in the
ass.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH] glx: don't force version == 2.0 for ES2 GLX context creation

[Ilia Mirkin]

dEQP tests request a specific version. The EXT spec has been updated to
allow other versions, so allow anything >= 2.0 to be requested.

Signed-off-by: Ilia Mirkin 
---
 glx/createcontext.c | 23 ---
 1 file changed, 4 insertions(+), 19 deletions(-)

diff --git a/glx/createcontext.c b/glx/createcontext.c
index d06bc1f..867c956 100644
--- a/glx/createcontext.c
+++ b/glx/createcontext.c
@@ -262,27 +262,12 @@ __glXDisp_CreateContextAttribsARB(__GLXclientState * cl, 
GLbyte * pc)
 case GLX_CONTEXT_ES2_PROFILE_BIT_EXT:
 /* The GLX_EXT_create_context_es2_profile spec says:
  *
- * "... If the version requested is 2.0, and the
- * GLX_CONTEXT_ES2_PROFILE_BIT_EXT bit is set in the
+ * "... If the version requested is a valid and supported OpenGL-ES
+ * version, and the GLX_CONTEXT_ES_PROFILE_BIT_EXT bit is set in 
the
  * GLX_CONTEXT_PROFILE_MASK_ARB attribute (see below), then the
- * context returned will implement OpenGL ES 2.0."
- *
- * It also says:
- *
- * "* If attribute GLX_CONTEXT_PROFILE_MASK_ARB has no bits set;
- *has any bits set other than
- *GLX_CONTEXT_CORE_PROFILE_BIT_ARB,
- *GLX_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB, or
- *GLX_CONTEXT_ES2_PROFILE_BIT_EXT; has more than one of these
- *bits set; or if the implementation does not supported the
- *requested profile, then GLXBadProfileARB is generated."
- *
- * It does not specifically say what is supposed to happen if
- * GLX_CONTEXT_ES2_PROFILE_BIT_EXT is set but the version requested is
- * not 2.0.  We choose to generate GLXBadProfileARB as this matches
- * NVIDIA's behavior.
+ * context returned will implement the OpenGL ES version 
requested."
  */
-if (major_version != 2 || minor_version != 0)
+if (major_version < 2)
 return __glXError(GLXBadProfileARB);
 break;
 default:
-- 
2.4.10

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] present: Handle wraparound when comparing MSC values

[Michel Dänzer]

On 16.01.2016 02:03, Keith Packard wrote:
> Michel Dänzer  writes:
> 
>> From: Michel Dänzer 
>>
>> When a window moves from one CRTC to another, present_window_to_crtc_msc
>> updates window_priv->msc_offset according to the delta between the
>> current MSC values of the old and new CRTC:
>>
>> window_priv->msc_offset += new_msc - old_msc;
>>
>> window_priv->msc_offset is initially 0, so if new_msc < old_msc,
>> window_priv->msc_offset wraps around and becomes a large number. If the
>> window_msc parameter passed in is small (in particular if it's 0, such as
>> is the case when the client just wants to know the current window MSC
>> value), the returned CRTC MSC value may still be a large number. In that
>> case, the existing MSC comparisons in pixmap_present weren't working as
>> intended, resulting in scheduling a wait far into the future when the
>> target MSC had actually already passed. This would result in the client
>> (e.g. the Chromium browser) hanging when moving its window between CRTCs.
>>
>> In order to fix this, introduce msc_is_(equal_or_)after helper functions
>> which take the wraparound into account for comparing two MSC values.
>>
>> Signed-off-by: Michel Dänzer 
> 
> 
> 
>> ---
>>  present/present.c | 32 +++-
>>  1 file changed, 27 insertions(+), 5 deletions(-)
>>
>> diff --git a/present/present.c b/present/present.c
>> index 66e0f21..8cf3b6f 100644
>> --- a/present/present.c
>> +++ b/present/present.c
>> @@ -717,6 +717,28 @@ present_execute(present_vblank_ptr vblank, uint64_t 
>> ust, uint64_t crtc_msc)
>>  present_vblank_destroy(vblank);
>>  }
>>  
>> +/*
>> + * Returns:
>> + * TRUE if the first MSC value is after the second one
>> + * FALSE if the first MSC value is equal to or before the second one
>> + */
>> +static Bool
>> +msc_is_after(uint64_t test, uint64_t reference)
>> +{
>> +return (int64_t)(test - reference) > 0;
>> +}
>> +
>> +/*
>> + * Returns:
>> + * TRUE if the first MSC value is equal to or after the second one
>> + * FALSE if the first MSC value is before the second one
>> + */
>> +static Bool
>> +msc_is_equal_or_after(uint64_t test, uint64_t reference)
>> +{
>> +return (int64_t)(test - reference) >= 0;
>> +}
>> +
> 
> These should probably get declared as inline, although the compiler will
> probably just inline them anyways.
> 
> I also won't be surprised if we end needing to expose these in a header
> for other code to use too. Should we just do that now so that someone
> needing to compare values finds them?
> 
> In any case; this all lgtm.
> 
> Reviewed-by: Keith Packard 

Thanks. May I push myself, or any takers?


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] present: Handle wraparound when comparing MSC values

[Martin Peres]

On 15/01/16 19:03, Keith Packard wrote:

Michel Dänzer  writes:


From: Michel Dänzer 

When a window moves from one CRTC to another, present_window_to_crtc_msc
updates window_priv->msc_offset according to the delta between the
current MSC values of the old and new CRTC:

 window_priv->msc_offset += new_msc - old_msc;

window_priv->msc_offset is initially 0, so if new_msc < old_msc,
window_priv->msc_offset wraps around and becomes a large number. If the
window_msc parameter passed in is small (in particular if it's 0, such as
is the case when the client just wants to know the current window MSC
value), the returned CRTC MSC value may still be a large number. In that
case, the existing MSC comparisons in pixmap_present weren't working as
intended, resulting in scheduling a wait far into the future when the
target MSC had actually already passed. This would result in the client
(e.g. the Chromium browser) hanging when moving its window between CRTCs.

In order to fix this, introduce msc_is_(equal_or_)after helper functions
which take the wraparound into account for comparing two MSC values.

Signed-off-by: Michel Dänzer 


So far, it seems to fix an issue I have had intermittently on my home 
machine which made it very hard to debug. I will keep you updated if I 
ever get a hang again with your patch applied.





---
  present/present.c | 32 +++-
  1 file changed, 27 insertions(+), 5 deletions(-)

diff --git a/present/present.c b/present/present.c
index 66e0f21..8cf3b6f 100644
--- a/present/present.c
+++ b/present/present.c
@@ -717,6 +717,28 @@ present_execute(present_vblank_ptr vblank, uint64_t ust, 
uint64_t crtc_msc)
  present_vblank_destroy(vblank);
  }
  
+/*

+ * Returns:
+ * TRUE if the first MSC value is after the second one
+ * FALSE if the first MSC value is equal to or before the second one
+ */
+static Bool
+msc_is_after(uint64_t test, uint64_t reference)
+{
+return (int64_t)(test - reference) > 0;
+}
+
+/*
+ * Returns:
+ * TRUE if the first MSC value is equal to or after the second one
+ * FALSE if the first MSC value is before the second one
+ */
+static Bool
+msc_is_equal_or_after(uint64_t test, uint64_t reference)
+{
+return (int64_t)(test - reference) >= 0;
+}
+

These should probably get declared as inline, although the compiler will
probably just inline them anyways.

I also won't be surprised if we end needing to expose these in a header
for other code to use too. Should we just do that now so that someone
needing to compare values finds them?


Sounds reasonable, indeed. Which header do you have in mind?



In any case; this all lgtm.

Reviewed-by: Keith Packard 


Same here, thanks for tracking this down!

Reviewed-by: Martin Peres 



___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH 3/8] glamor: Use vertex arrays

[Eric Anholt]

Dave Airlie  writes:

> From: Keith Packard 
>
> Core contexts require the use of vertex arrays, so switch both glamor
> and ephyr/glamor over.

I had been thinking of doing serious VAO usage, where each path set up
its VAO so that the driver could precompute state (like what you did in
GLX here).  This is way more incremental, and I like it a lot.

Reviewed-by: Eric Anholt 


signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH 4/8] glamor: Use GL_RED instead of GL_ALPHA if we have texture_swizzle

[Eric Anholt]

Dave Airlie  writes:

> From: Keith Packard 
>
> GL_RED is supported by core profiles while GL_ALPHA is not; use GL_RED
> for one channel objects (depth 1 to 8), and then swizzle them into the
> alpha channel when used as a mask.
>
> [airlied: updated to master, add swizzle to composited glyphs and xv paths]
>
> Signed-off-by: Keith Packard 
> Signed-off-by: Dave Airlie 
> ---
>  glamor/glamor.c  |  4 
>  glamor/glamor_composite_glyphs.c |  5 +
>  glamor/glamor_fbo.c  |  2 ++
>  glamor/glamor_picture.c  | 22 ++
>  glamor/glamor_priv.h |  2 ++
>  glamor/glamor_render.c   |  9 +
>  glamor/glamor_transfer.c |  2 +-
>  glamor/glamor_utils.h|  4 +++-
>  glamor/glamor_xv.c   | 12 
>  9 files changed, 52 insertions(+), 10 deletions(-)
>
> diff --git a/glamor/glamor.c b/glamor/glamor.c
> index 8828ad3..7fa3a46 100644
> --- a/glamor/glamor.c
> +++ b/glamor/glamor.c
> @@ -596,6 +596,10 @@ glamor_init(ScreenPtr screen, unsigned int flags)
>  glamor_priv->max_fbo_size = MAX_FBO_SIZE;
>  #endif
>  
> +glamor_priv->one_channel_format = GL_ALPHA;
> +if (epoxy_has_gl_extension("GL_ARB_texture_rg") && 
> epoxy_has_gl_extension("GL_ARB_texture_swizzle"))
> +glamor_priv->one_channel_format = GL_RED;
> +
>  glamor_set_debug_level(_debug_level);
>  
>  glamor_priv->saved_procs.create_screen_resources =
> diff --git a/glamor/glamor_composite_glyphs.c 
> b/glamor/glamor_composite_glyphs.c
> index fb31340..5f0fda5 100644
> --- a/glamor/glamor_composite_glyphs.c
> +++ b/glamor/glamor_composite_glyphs.c
> @@ -247,6 +247,11 @@ glamor_glyphs_flush(CARD8 op, PicturePtr src, PicturePtr 
> dst,
>  glActiveTexture(GL_TEXTURE1);
>  glBindTexture(GL_TEXTURE_2D, atlas_fbo->tex);
>  
> +if (glamor_priv->one_channel_format == GL_RED &&
> +atlas->atlas->drawable.depth <= 8)
> +{
> +glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_SWIZZLE_A, GL_RED);
> +}
>  for (;;) {
>  if (!glamor_use_program_render(prog, op, src, dst))
>  break;

Since these TexParameters are stored in the texture object, I think what
we really want is when we make an 8-bit FBO, at that point set SWIZZLE_A
to RED and SWIZZLE_RED to 0.  (If we don't do RED to 0, I expect this
will cause Render regressions).  Then we don't have to do these
expensive TexParameters at draw time.


signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH 5/8] glamor: add core profile support.

[Eric Anholt]

Dave Airlie  writes:

> From: Dave Airlie 
>
> This adds a new flag to glamor_init to denote the context is
> core profile.
>
> This flag is used to disable quads for rendering.
>
> Signed-off-by: Dave Airlie 
> ---
>  glamor/glamor.c | 3 ++-
>  glamor/glamor.h | 3 ++-
>  2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/glamor/glamor.c b/glamor/glamor.c
> index 7fa3a46..a2bd687 100644
> --- a/glamor/glamor.c
> +++ b/glamor/glamor.c
> @@ -578,7 +578,8 @@ glamor_init(ScreenPtr screen, unsigned int flags)
>  
>  glamor_setup_debug_output(screen);
>  
> -glamor_priv->use_quads = (glamor_priv->gl_flavor == GLAMOR_GL_DESKTOP);
> +glamor_priv->use_quads = (glamor_priv->gl_flavor == GLAMOR_GL_DESKTOP) 
> && !(glamor_priv->flags & GLAMOR_USE_CORE_PROFILE);
> +

Instead of having the context creator pass us a flag, couldn't we just
have

bool core_context = gl_version >= 32 && 
!epoxy_has_gl_extension("GL_ARB_compatibility")?


signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH 6/8] ephyr: Create 3.3 core profile context if possible (v2)

[Eric Anholt]

Dave Airlie  writes:

> From: Keith Packard 
>
> On desktop GL, Ask for a 3.3 core profile context if that's available,
> otherwise create a generic context.
>
> v2: tell glamor the profile is a core one.
>
> Signed-off-by: Keith Packard 
> Signed-off-by: Dave Airlie 
> ---
>  hw/kdrive/ephyr/ephyr_glamor_glx.c | 19 +--
>  hw/kdrive/ephyr/ephyr_glamor_glx.h |  2 +-
>  hw/kdrive/ephyr/hostx.c|  7 +--
>  3 files changed, 23 insertions(+), 5 deletions(-)
>
> diff --git a/hw/kdrive/ephyr/ephyr_glamor_glx.c 
> b/hw/kdrive/ephyr/ephyr_glamor_glx.c
> index 30c5245..674e7f5 100644
> --- a/hw/kdrive/ephyr/ephyr_glamor_glx.c
> +++ b/hw/kdrive/ephyr/ephyr_glamor_glx.c
> @@ -277,7 +277,7 @@ ephyr_glamor_process_event(xcb_generic_event_t *xev)
>  }
>  
>  struct ephyr_glamor *
> -ephyr_glamor_glx_screen_init(xcb_window_t win)
> +ephyr_glamor_glx_screen_init(xcb_window_t win, Bool *profile_is_core)
>  {
>  static const float position[] = {
>  -1, -1,
> @@ -295,6 +295,7 @@ ephyr_glamor_glx_screen_init(xcb_window_t win)
>  struct ephyr_glamor *glamor;
>  GLXWindow glx_win;
>  
> +*profile_is_core = FALSE;
>  glamor = calloc(1, sizeof(struct ephyr_glamor));
>  if (!glamor) {
>  FatalError("malloc");
> @@ -319,7 +320,21 @@ ephyr_glamor_glx_screen_init(xcb_window_t win)
> "GLX_EXT_create_context_es2_profile\n");
>  }
>  } else {
> -ctx = glXCreateContext(dpy, visual_info, NULL, True);
> +static const int context_attribs[] = {
> +GLX_CONTEXT_PROFILE_MASK_ARB,
> +GLX_CONTEXT_CORE_PROFILE_BIT_ARB,
> +GLX_CONTEXT_MAJOR_VERSION_ARB,
> +3,
> +GLX_CONTEXT_MINOR_VERSION_ARB,
> +3,
> +0,
> +};
> +ctx = glXCreateContextAttribsARB(dpy, fb_config, NULL, True,
> + context_attribs);
> +if (!ctx)
> +ctx = glXCreateContext(dpy, visual_info, NULL, True);
> +else
> +*profile_is_core = TRUE;
>  }

Before using the new function, we need to check
epoxy_has_glx_extension("GLX_ARB_create_context")


signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: glamor core profile support

[Eric Anholt]

r<#secure method=pgpmime mode=sign>
Marek Olšák  writes:

> On Tue, Jan 19, 2016 at 1:56 AM, Dave Airlie  wrote:
>> This series implements support for glamor in ephyr/EGL/Xwayland
>> to use GL core profile when it can.
>>
>> This required 4 main changes:
>> a) stop using client ptrs everywhere, I found 3 places left,
>> gradient, picture and xv where we use these.
>> b) start using VAOs
>> c) use GL_RED instead of GL_ALPHA
>> d) stop using GL_QUADS.
>
> Won't this negatively affect performance on drivers which can do quads 
> natively?

You've probably got instancing, though, and most of our high-vertex-rate
code will use that with triangle strips to reduce vertex attribute data
anyway (see glamor_text.c).
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel