With EXA almost a lot of stuff is rendered with "algorithm" - draw upper part of the widget/symbol (~1/2 - 2/3) instantly and lower part after ~0.5s delay. I'm using latest KDE3 desktop with Lightv3 widget theme if it matters. The problem is 100% there with mouse hover (toolbar icons etc) and with text rendering (even blinking cursor in textedit areas is affected). I'm using server 1.4.0 with intel driver 2.2.0.
Created attachment 12663 [details] Xorg log
Would you try it if enable DRI?
and please attach your xorg.conf. thanks.
DragonFly BSD doesn't have DRI support.
Created attachment 12753 [details] xorg.conf
DragonFly has DRI support now and indeed it helps a lot. But I have feeling that this delayed rendering isn't specific to EXA and noDRI. At least I can see delayed rendering of some parts of the blinking cursor sometimes with XAA/noDRI as well - just because XAA is so much faster, it doesn't annoy much. EXA/DRI combination isn't useful from practical point of view for me though, because I can get it to crash quite easily - just switching KDE windows fullscreen and back. I'll open separate bugreport for this.
Is this bug still valid? or you would fire another bug for other issues?
The bug is still valid, but I haven't tried to upgrade to the stable branches yet, I'm still using releases. I'll try latest intel 2.2 and 1.4 server branch soon. AFAICS 1.4 server branch got a lot of fixes regarding EXA. EXA/DRI combination crashes I mentioned in the comment #6 will not get freedesktop.org bug at least for now. It's either problem with drm port for DragonFly not yet pushed to upstream or drm itself. I opened bugs for all other issues I found so far which are (I think) related to the intel driver: #13976 and #13985.
I switched to xorg-server-1.4.0.90.tar.gz and nothing changed.
So any possible to do some profile? like oprofile, to know what things might cause the delay.
Does starting the X server with the command line option -dumbSched make any difference?
DragonFly BSD doesn't have oprofile or any stable profiling solution which would use hardware performance counters. Hopefully it will change soon. No, -dumbSched doesn't make any difference. But while testing it, I discovered that I can't reproduce the problem at all in my laptop using 965GM chip. So, is it specific to 965Q?
Does your system on 965GM have DRI enabled? What I can guess now is relate to vblank issue, windows manager trys to sync with vblank and something seems wrong in non-DRI case. but I don't know the details of its current status in drivers...
Sync to vblank isn't currently possible without the DRI.
No, I disabled DRI on 965GM system as well for tests and EXA without DRI is just plain slow on this system (I think that #13389 covers this already?). The bug doesn't appear in either system while using DRI.
(In reply to comment #14) > Sync to vblank isn't currently possible without the DRI. > Michel, where could I look more into this? Do you mean XSync won't bind with drm vblank irq if DRI is disabled?
(In reply to comment #16) There is no sync-to-vblank SYNC code in the server. Only the DRM has sync-to-vblank facilities at this point.
Could you try my test patch on bug #14523?
The patch from bug #14523 didn't change anything regarding this issue.
Eric has pushed fix to upstream master, could you test again? It does fix no dri issue on 965, but I'm not sure your problem is bsd relate or not.
I tested xf86-video-intel-2.2.99.902 and the problem seems to be fixed. Thanks!
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.