Re: [PATCH] glamor: fix glamor_xv_query_image_attributes() for odd-width images

[Adam Jackson]

On Tue, 2018-04-17 at 22:22 +0100, David Woodhouse wrote:

> Images which are one pixel wider than a multiple of 8 are being handled
> incorrectly. Other drivers round up the width to a multiple of two
> before they start calculating. Do the same.
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=795235
> 
> Signed-off-by: David Woodhouse 

Nice catch. Merged, thanks:

remote: I: patch #217542 updated using rev 
12a6b189fb17894d2c3851b70a396bbf41f444c6.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   ac7a4bf44c..12a6b189fb  master -> master

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

[PATCH] glamor: fix glamor_xv_query_image_attributes() for odd-width images

[David Woodhouse]

Images which are one pixel wider than a multiple of 8 are being handled
incorrectly. Other drivers round up the width to a multiple of two
before they start calculating. Do the same.

https://bugzilla.gnome.org/show_bug.cgi?id=795235

Signed-off-by: David Woodhouse 
---
 glamor/glamor_xv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/glamor/glamor_xv.c b/glamor/glamor_xv.c
index e0375d7cd..62fc4fff5 100644
--- a/glamor/glamor_xv.c
+++ b/glamor/glamor_xv.c
@@ -210,6 +210,7 @@ glamor_xv_query_image_attributes(int id,
 switch (id) {
 case FOURCC_YV12:
 case FOURCC_I420:
+*w = ALIGN(*w, 2);
 *h = ALIGN(*h, 2);
 size = ALIGN(*w, 4);
 if (pitches)
-- 
2.14.3

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

Re: [PATCH xserver 1/3] os/WaitFor: Check timers on every iteration

[Adam Jackson]

On Sun, 2018-04-15 at 15:40 +0100, Chris Wilson wrote:
> Currently we only check timer expiry if there are no client fd (or
> other input) waiting to be serviced. This makes it very easy to starve
> the timers with long request queues, and so miss critical timestamps.
> 
> The timer subsystem is just another input waiting to be serviced, so
> evaluate it on every loop like all the others, at the cost of calling
> GetTimeInMillis() slightly more frequently. (A more invasive and likely
> OS specific alternative would be to move the timer wheel to the local
> equivalent of timerfd, and treat it as an input fd to the event loop
> exactly equivalent to all the others, and so also serviced on every
> pass. The trade-off being that the kernel timer wheel is likely more
> efficiently integrated with epoll, but individual updates to each timer
> would then require syscalls.)
> 
> Signed-off-by: Chris Wilson 

11:31 < pharris> "os/WaitFor: Check timers on every iteration" has my 
 reviewed-by. We've been shipping an equivalent patch for a 
 while.
11:32 < pharris> I'd reply on-list, but the email server bounced too many 
 messages and I got auto-unsubscribed.
11:33 < pharris> The other two patches in the series have my r-b too, I guess. 
 They look like obvious clean-ups.

And indeed they do, but I'm trying to stay cautious as we inch towards
release. So, merged this one, will queue the other two for after
release:

remote: I: patch #217184 updated using rev 
ac7a4bf44c68c5f323375974b208d4530fb5b60f.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   78b6f94021..ac7a4bf44c  master -> master

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

Re: Has anyone noticed severe performance regression since X Server 1.18?

[Adam Jackson]

On Tue, 2018-04-17 at 19:53 +0200, Kevin Brace wrote:

> When EXA is in use, the performance is roughly something like Version
> 1.11 > Version 1.15 > Version 1.18 / 1.19.

Surely a profile would show different results between these points.
There's something like 2000 commits between 1.15 and 1.18, I'm not sure
I could guess which one might be your culprit without a little more
detail than "something got slow". But since I can't help myself...

As you're not accelerated you're probably using shadowfb. There's been
basically only one major change there since 1.15:

https://cgit.freedesktop.org/xorg/xserver/commit/?id=2dcb1672620ef5f16111517e9e7a98cf97deb678

I would be somewhat surprised if that turned out to be the guilty
commit, as the damage code has to do all the same work, but it's
possible the old CopyWindow hook was a real win.

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

Has anyone noticed severe performance regression since X Server 1.18?

[Kevin Brace]

Hi,

Due to myself working on OpenChrome graphics (VIA Technologies Chrome 
integrated graphics) stack, I have increasingly noticed X Server performance 
issues since Version 1.18 since I use fairly old computers for DRM development.
I posted about this while back, but got very little attention.

https://lists.x.org/archives/xorg-devel/2017-July/054210.html

The only person who replied to it blamed it on SiS DDX's incomplete EXA 
implementation.
I actually think it affects all devices, in my opinion.
Since that post, I got many issues that affected the stability of OpenChrome 
DRM stabilized, so I am now in a position where I can use OpenChrome DDX + 
OpenChrome DRM without major stability issues.
Hence, this brings me to the X Server severe performance regression issue that 
has been bothering me.
Just for disclosure, there is currently no 2D acceleration for OpenChrome 
DDX + OpenChrome DRM, hence the rendering speed is fairly slow.
That being said, everything seems very slow with X Server Version 1.19.
For example, the hardware I use has hardware cursor, but the cursor movement 
speed is very sluggish, and comes with annoying hiccups when moving the mouse 
cursor.
I am wondering if the X Server is performing excessive task switching that it 
did not used to do with Version 1.15.
Window dragging movement is much slower with Version 1.19 versus much speedier 
Version 1.15, and again, without 2D acceleration we are talking about here.
For OpenChrome DRM development, I actively maintain two branches.
I call them drm-next-3.19 branch and drm-next-4.18 branch.

https://cgit.freedesktop.org/openchrome/drm-openchrome/

drm-next-3.19 branch is tested mainly with X Server 1.15 and XFCE (i.e., 
Xubuntu 14.04.1 without hardware enablement) and drm-next-4.18 branch is tested 
mainly with X Server 1.19 and XFCE (i.e., Xubuntu 16.04.4)
Again, due to lack of experience and resources, there is no 2D acceleration for 
OpenChrome DDX + OpenChrome DRM at this time.
OpenChrome DRM code is essentially the same between the two branches.
When it comes to performance, drm-next-3.19 branch's code performs far better, 
and it appears that X Server 1.15 is the reason for this.
Some reading this might want to blame me for the lack of 2D acceleration, 
but for OpenChrome, we do still have 2D acceleration support (EXA) when not 
using OpenChrome DRM, and the performance has been going down since X Server 
1.11 (i.e., Lubuntu 12.04).
When EXA is in use, the performance is roughly something like Version 1.11 > 
Version 1.15 > Version 1.18 / 1.19.
Rendering / window movement performance has been going down for the last 6 
years even with the same exact DDX code (OpenChrome DDX can be compiled 
unmodified all the way back to X Server Version 1.7), and this is particularly 
noticeable with older computers.
Perhaps, this issue cannot be dealt with before X Server Version 1.20 is 
released, but if someone knowledgeable with it can look into it during X Server 
Version 1.21 development cycle, that will be appreciated.

Kevin Brace
Brace Computer Laboratory blog
https://bracecomputerlab.com


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

Re: [PATCH xserver] modesetting: Fix inverted check in dri2 WaitMSC

[Adam Jackson]

On Mon, 2018-04-16 at 22:58 +, Mike Lothian wrote:
> I've applied this too as part of my testing, I don't see a dri3 file
> - does that mean the dri2 one covers both dri2&3?

It covers just DRI2. In the DRI3 model the equivalent operation lives
in Present (.../present.c), and the code there does not have this bug.

> If it doesn't please ignore
> 
> Tested-by: Mike Lothian 

Merged, thanks:

remote: I: patch #217290 updated using rev 
78b6f940217c127f0f345b7710aa5994c6ded99c.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   4e92c51ce4..78b6f94021  master -> master

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

Re: [PATCH xserver] dri3: Fix dri3_buffers_from_pixmap request.

[Adam Jackson]

On Mon, 2018-04-16 at 21:27 +, Mike Lothian wrote:
> Tested-by: Mike Lothian 

remote: I: patch #217200 updated using rev 
4e92c51ce4d6ab50c1507a23a01c6be0d1954d79.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   a98a95b798..4e92c51ce4  master -> master

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

Re: [PATCH xserver] modesetting: Fix inverted check in dri2 WaitMSC

[Walter Harms]

> Frank Binns  hat am 16. April 2018 um 22:17
> geschrieben:
> 
> 
> Adam Jackson  writes:
> 
> > ms_queue_vblank() returns false on failure.
> >
> > Reported-by: Chris Wilson 
> > Signed-off-by: Adam Jackson 
> 
> Reviewed-by: Frank Binns 
> 
> > ---
> >  hw/xfree86/drivers/modesetting/dri2.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/hw/xfree86/drivers/modesetting/dri2.c
> > b/hw/xfree86/drivers/modesetting/dri2.c
> > index fd36aa118..96ef7 100644
> > --- a/hw/xfree86/drivers/modesetting/dri2.c
> > +++ b/hw/xfree86/drivers/modesetting/dri2.c
> > @@ -749,7 +749,7 @@ ms_dri2_schedule_wait_msc(ClientPtr client, DrawablePtr
> > draw, CARD64 target_msc,
> >  target_msc = current_msc;
> >  
> >  ret = ms_queue_vblank(crtc, MS_QUEUE_ABSOLUTE, target_msc,
> > _msc, seq);
> > -if (ret) {
> > +if (!ret) {
> >  static int limit = 5;
> >  if (limit) {
> >  xf86DrvMsg(scrn->scrnIndex, X_WARNING,
> 


A few lines later there is:

if (!ms_queue_vblank(crtc, MS_QUEUE_ABSOLUTE, request_msc, _msc,
seq)) {
static int limit = 5;
if (limit) {
xf86DrvMsg(scrn->scrnIndex, X_WARNING,
   "%s:%d get vblank counter failed: %s\n",
   __FUNCTION__, __LINE__,
   strerror(errno));
limit--;
}
goto out_free;
}

perhaps that can be changed into the same style ?
Either with or without ret i do not care but the same.

re,
 wh


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