X hardware acceleration still flaky?

X hardware acceleration still flaky?

[L.Wood]

Well, it's been eighteen months since I last asked:
http://www.cygwin.com/ml/cygwin-xfree/2009-02/msg00259.html

so I attempted to use opengl hardware acceleration with Cygwin and XFree 7.4, using Geomview (www.geomview.org) as the test application on an uptodate Cygwin 1.7 install.

Lots of flickering for about thirty seconds (of correct output), but then the X server crashes. So, no visible change over previous. It's still a regression on pre-7.4.

Has any work been attempted on improving hardware acceleration in xwin-gl?

thanks,

L.

SaVi satellite constellation visualization http://savi.sf.net/




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

Re: X hardware acceleration still flaky?

[Jon TURNEY]

On 08/08/2010 10:18, L.Wood@surrey.ac.uk wrote:
> Well, it's been eighteen months since I last asked:
> http://www.cygwin.com/ml/cygwin-xfree/2009-02/msg00259.html

> so I attempted to use opengl hardware acceleration with Cygwin and XFree 7.4, using Geomview (www.geomview.org) as the test application on an uptodate Cygwin 1.7 install.
>
> Lots of flickering for about thirty seconds (of correct output), but then the X server crashes. So, no visible change over previous. It's still a regression on pre-7.4.

I'm not sure what you were testing here, but I can't see how it could be 
hardware AIGLX.

xwin-gl is obsolete, an empty package since R7.4 [1], so if you are running 
that somehow, it must be an old version, which I am surprised works at all.

Alternatively, you are using xwin with software rendering, and your 
application exposes some bug in the Xserver which makes it crash.


I am happy to work with you to resolve these issues.

> Has any work been attempted on improving hardware acceleration in xwin-gl?

Yes, this is something I have been working on in my copious free time(TM):

http://cygwin.com/ml/cygwin-xfree/2009-06/msg00088.html
http://sourceware.org/ml/cygwin-xfree/2009-08/msg00021.html
http://x.cygwin.com/devel/todo.html

I hope you'll note that savi is one of the applications I've been testing with.

However, given the lack of response so far, it seems that you and me are the 
only 2 people interested in working AIGLX for XWin :-)

I wouldn't suggest testing with those binaries at this stage, as I've moved on 
a bit.  I hope to shortly make another test release containing AIGLX based on 
the upcoming Xserver 1.9, and I would very much appreciate some testing of the 
AIGLX functionality in that, when it is available.

[1] http://cygwin.com/cgi-bin2/package-grep.cgi?grep=xwin-gl

-- 
Jon TURNEY
Volunteer Cygwin/X X Server maintainer

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

Re: X hardware acceleration still flaky?

[L.Wood]

Hi Jon,

I just downloaded the current X server and its libraries in the Cygwin distro; the xwin-gl allusion came from the previous thread I mentioned.

Compiling geomview 1.9.4 --with-opengl is straightforward (that's one improvement on pre-7.4 X; configure doesn't get confused about X library locations and building is easier). I then tried running savi with geomview:
- using OpenGL. 30 seconds of slow flickering (slow enough to be the software rendering that you alluded to?), then the X server consistently crashes, even before I've had a chance to turn on texturemapping...
- forcing internal geomview software rendering using geomview -noopengl -run ../savi1.4.3/savi $* . Works, but is rather stately. No texturemapping support, obviously. Less slow than the brief opengl attempt, though, which figures given that doing OpenGL in software imposes more layers of overhead?

That's the status from testing with what cygwin ships at the moment. I haven't tried your older binaries. Please let me know when you get to another test release, and I'll try it out.

thanks,

L.

SaVi satellite constellation visualization http://savi.sf.net/

On 8 Aug 2010, at 13:57, Jon TURNEY wrote:

> On 08/08/2010 10:18, L.Wood@surrey.ac.uk wrote:
>> Well, it's been eighteen months since I last asked:
>> http://www.cygwin.com/ml/cygwin-xfree/2009-02/msg00259.html
> 
>> so I attempted to use opengl hardware acceleration with Cygwin and XFree 7.4, using Geomview (www.geomview.org) as the test application on an uptodate Cygwin 1.7 install.
>> 
>> Lots of flickering for about thirty seconds (of correct output), but then the X server crashes. So, no visible change over previous. It's still a regression on pre-7.4.
> 
> I'm not sure what you were testing here, but I can't see how it could be 
> hardware AIGLX.
> 
> xwin-gl is obsolete, an empty package since R7.4 [1], so if you are running 
> that somehow, it must be an old version, which I am surprised works at all.
> 
> Alternatively, you are using xwin with software rendering, and your 
> application exposes some bug in the Xserver which makes it crash.
> 
> 
> I am happy to work with you to resolve these issues.
> 
>> Has any work been attempted on improving hardware acceleration in xwin-gl?
> 
> Yes, this is something I have been working on in my copious free time(TM):
> 
> http://cygwin.com/ml/cygwin-xfree/2009-06/msg00088.html
> http://sourceware.org/ml/cygwin-xfree/2009-08/msg00021.html
> http://x.cygwin.com/devel/todo.html
> 
> I hope you'll note that savi is one of the applications I've been testing with.
> 
> However, given the lack of response so far, it seems that you and me are the 
> only 2 people interested in working AIGLX for XWin :-)
> 
> I wouldn't suggest testing with those binaries at this stage, as I've moved on 
> a bit.  I hope to shortly make another test release containing AIGLX based on 
> the upcoming Xserver 1.9, and I would very much appreciate some testing of the 
> AIGLX functionality in that, when it is available.
> 
> [1] http://cygwin.com/cgi-bin2/package-grep.cgi?grep=xwin-gl
> 
> -- 
> Jon TURNEY
> Volunteer Cygwin/X X Server maintainer




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

Re: X hardware acceleration still flaky?

[Jon TURNEY]

On 08/08/2010 15:57, L.Wood@surrey.ac.uk wrote:
> Hi Jon,
>
> I just downloaded the current X server and its libraries in the Cygwin distro; the xwin-gl allusion came from the previous thread I mentioned.

So, the current problem is with OpenGL on X.

"OpenGL" and "hardware acceleration" are not synonyms.

Testing with the experimental AIGLX code is moot if it doesn't work with the 
current X server.

> Compiling geomview 1.9.4 --with-opengl is straightforward (that's one improvement on pre-7.4 X; configure doesn't get confused about X library locations and building is easier). I then tried running savi with geomview:
> - using OpenGL. 30 seconds of slow flickering (slow enough to be the software rendering that you alluded to?), then the X server consistently crashes, even before I've had a chance to turn on texturemapping...

I've built savi and geomview, and I'm afraid I can't reproduce this crash.

There's no flickering unless I use the mouse to rotate the planet, which 
almost looks like it's not using double-buffering for some reason, as the 
whole frame looks like it's being drawn into the front buffer...


I've rebuilt X server 1.8.2-1 with debugging symbols and uploaded it at [1], 
can you run that under gdb and reproduce your crash and post a backtrace, please.

[1] ftp://cygwin.com/pub/cygwinx/XWin.20100808-git-66f3680cb47fbd09.exe.bz2

> - forcing internal geomview software rendering using geomview -noopengl -run ../savi1.4.3/savi $* . Works, but is rather stately. No texturemapping support, obviously. Less slow than the brief opengl attempt, though, which figures given that doing OpenGL in software imposes more layers of overhead?
>
> That's the status from testing with what cygwin ships at the moment. I haven't tried your older binaries. Please let me know when you get to another test release, and I'll try it out.
>
> thanks,
>
> L.
>
> SaVi satellite constellation visualization http://savi.sf.net/
>
> On 8 Aug 2010, at 13:57, Jon TURNEY wrote:
>
>> On 08/08/2010 10:18, L.Wood@surrey.ac.uk wrote:
>>> Well, it's been eighteen months since I last asked:
>>> http://www.cygwin.com/ml/cygwin-xfree/2009-02/msg00259.html
>>
>>> so I attempted to use opengl hardware acceleration with Cygwin and XFree 7.4, using Geomview (www.geomview.org) as the test application on an uptodate Cygwin 1.7 install.
>>>
>>> Lots of flickering for about thirty seconds (of correct output), but then the X server crashes. So, no visible change over previous. It's still a regression on pre-7.4.
>>
>> I'm not sure what you were testing here, but I can't see how it could be
>> hardware AIGLX.
>>
>> xwin-gl is obsolete, an empty package since R7.4 [1], so if you are running
>> that somehow, it must be an old version, which I am surprised works at all.
>>
>> Alternatively, you are using xwin with software rendering, and your
>> application exposes some bug in the Xserver which makes it crash.
>>
>>
>> I am happy to work with you to resolve these issues.
>>
>>> Has any work been attempted on improving hardware acceleration in xwin-gl?
>>
>> Yes, this is something I have been working on in my copious free time(TM):
>>
>> http://cygwin.com/ml/cygwin-xfree/2009-06/msg00088.html
>> http://sourceware.org/ml/cygwin-xfree/2009-08/msg00021.html
>> http://x.cygwin.com/devel/todo.html
>>
>> I hope you'll note that savi is one of the applications I've been testing with.
>>
>> However, given the lack of response so far, it seems that you and me are the
>> only 2 people interested in working AIGLX for XWin :-)
>>
>> I wouldn't suggest testing with those binaries at this stage, as I've moved on
>> a bit.  I hope to shortly make another test release containing AIGLX based on
>> the upcoming Xserver 1.9, and I would very much appreciate some testing of the
>> AIGLX functionality in that, when it is available.
>>
>> [1] http://cygwin.com/cgi-bin2/package-grep.cgi?grep=xwin-gl

-- 
Jon TURNEY
Volunteer Cygwin/X X Server maintainer

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

RE: X hardware acceleration still flaky?

[L.Wood]

Hi Jon,

the lack of flickering and lack of double-buffering you describe sounds like geomview being run without opengl, either  because it has been compiled without opengl (still the default if you just type ./configure, I believe), or because
geomview -noopengl
was issued. Did you build Geomview with --with-opengl, and have you turned on a texturemapped Earth showing coloured continents? (If geomview issues a 'Shared memory unavailable, using fallback display method' to stderr at launch, it's not using OpenGL.)

When geomview is run with opengl, I see consistent flickering at every single animation stage, not just when dragging with the mouse. -noopengl is much smoother. (I'm using a fairly high-end Core2Duo with graphic card.)

I've now realised that my crashes only occur when I use the second screen attached to my machine. (Mea culpa - I take multiple screens for granted.) When geomview's camera is on the root (laptop) screen, X doesn't crash, even when texturemapping, and I get slow but flickery animations of texturemapped Earths. Move it over to the second screen and do something that invokes texturemapping like turning on a detailed Earth - goodbye, Mr X.

It's a little odd that XWin.0.log doesn't explicitly call out the two screens as such - it knows the primary (laptop) monitor is 1280 by 800, and that DIB has a height of 1824 because there's a 1280x1024 screen positioned above it.

$ less /var/log XWin.0.log
Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 1.8.0.0 (10800000)
Build Date: 2010-04-02

Contact: cygwin-xfree@cygwin.com
XWin was started with the following command line:

X :0 -multiwindow 

ddxProcessArgument - Initializing default screens
winInitializeDefaultScreens - primary monitor w 1280 h 800
winInitializeDefaultScreens - native DPI x 96 y 96
winInitializeDefaultScreens - Returning
[534027.271] winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1
[534027.286] (II) xorg.conf is not supported
[534027.286] (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information
[534027.286] LoadPreferences: /home/lw0011/.XWinrc not found
[534027.286] LoadPreferences: Loading /etc/X11/system.XWinrc
[534027.286] LoadPreferences: Done parsing the configuration file...
[534027.286] winGetDisplay: DISPLAY=:0.0
[534027.302] winDetectSupportedEngines - Windows NT/2000/XP
[534027.380] winDetectSupportedEngines - DirectDraw installed
[534027.380] winDetectSupportedEngines - DirectDraw4 installed
[534027.380] winDetectSupportedEngines - Returning, supported engines 00000007
[534027.380] winSetEngine - Multi Window or Rootless => ShadowGDI
[534027.380] winAdjustVideoModeShadowGDI - Using Windows display depth of 32 bits per pixel
[534027.458] winAllocateFBShadowGDI - Creating DIB with width: 1280 height: 1824 depth: 32
[534027.458] winFinishScreenInitFB - Masks: 00ff0000 0000ff00 000000ff
[534027.458] winInitVisualsShadowGDI - Masks 00ff0000 0000ff00 000000ff BPRGB 8 d 24 bpp 32
[534027.458] null screen fn ReparentWindow
[534027.458] null screen fn RestackWindow
[534027.458] InitQueue - Calling pthread_mutex_init
[534027.458] InitQueue - pthread_mutex_init returned
[534027.458] InitQueue - Calling pthread_cond_init
[534027.458] InitQueue - pthread_cond_init returned
[534027.458] winInitMultiWindowWM - Hello
[534027.474] winInitMultiWindowWM - Calling pthread_mutex_lock ()
 
Is it still useful to give you a bt from gdb?

thanks,

L.
-----Original Message-----
From: Jon TURNEY [mailto:jon.turney@dronecode.org.uk] 
Sent: 09 August 2010 13:43
To: cygwin-xfree@cygwin.com
Cc: Wood L Dr (Electronic Eng)
Subject: Re: X hardware acceleration still flaky?
Importance: High

On 08/08/2010 15:57, L.Wood@surrey.ac.uk wrote:
> Hi Jon,
>
> I just downloaded the current X server and its libraries in the Cygwin distro; the xwin-gl allusion came from the previous thread I mentioned.

So, the current problem is with OpenGL on X.

"OpenGL" and "hardware acceleration" are not synonyms.

Testing with the experimental AIGLX code is moot if it doesn't work with the current X server.

> Compiling geomview 1.9.4 --with-opengl is straightforward (that's one improvement on pre-7.4 X; configure doesn't get confused about X library locations and building is easier). I then tried running savi with geomview:
> - using OpenGL. 30 seconds of slow flickering (slow enough to be the software rendering that you alluded to?), then the X server consistently crashes, even before I've had a chance to turn on texturemapping...

I've built savi and geomview, and I'm afraid I can't reproduce this crash.

There's no flickering unless I use the mouse to rotate the planet, which almost looks like it's not using double-buffering for some reason, as the whole frame looks like it's being drawn into the front buffer...


I've rebuilt X server 1.8.2-1 with debugging symbols and uploaded it at [1], can you run that under gdb and reproduce your crash and post a backtrace, please.

[1] ftp://cygwin.com/pub/cygwinx/XWin.20100808-git-66f3680cb47fbd09.exe.bz2

> - forcing internal geomview software rendering using geomview -noopengl -run ../savi1.4.3/savi $* . Works, but is rather stately. No texturemapping support, obviously. Less slow than the brief opengl attempt, though, which figures given that doing OpenGL in software imposes more layers of overhead?
>
> That's the status from testing with what cygwin ships at the moment. I haven't tried your older binaries. Please let me know when you get to another test release, and I'll try it out.
>
> thanks,
>
> L.
>
> SaVi satellite constellation visualization http://savi.sf.net/
>
> On 8 Aug 2010, at 13:57, Jon TURNEY wrote:
>
>> On 08/08/2010 10:18, L.Wood@surrey.ac.uk wrote:
>>> Well, it's been eighteen months since I last asked:
>>> http://www.cygwin.com/ml/cygwin-xfree/2009-02/msg00259.html
>>
>>> so I attempted to use opengl hardware acceleration with Cygwin and XFree 7.4, using Geomview (www.geomview.org) as the test application on an uptodate Cygwin 1.7 install.
>>>
>>> Lots of flickering for about thirty seconds (of correct output), but then the X server crashes. So, no visible change over previous. It's still a regression on pre-7.4.
>>
>> I'm not sure what you were testing here, but I can't see how it could 
>> be hardware AIGLX.
>>
>> xwin-gl is obsolete, an empty package since R7.4 [1], so if you are 
>> running that somehow, it must be an old version, which I am surprised works at all.
>>
>> Alternatively, you are using xwin with software rendering, and your 
>> application exposes some bug in the Xserver which makes it crash.
>>
>>
>> I am happy to work with you to resolve these issues.
>>
>>> Has any work been attempted on improving hardware acceleration in xwin-gl?
>>
>> Yes, this is something I have been working on in my copious free time(TM):
>>
>> http://cygwin.com/ml/cygwin-xfree/2009-06/msg00088.html
>> http://sourceware.org/ml/cygwin-xfree/2009-08/msg00021.html
>> http://x.cygwin.com/devel/todo.html
>>
>> I hope you'll note that savi is one of the applications I've been testing with.
>>
>> However, given the lack of response so far, it seems that you and me 
>> are the only 2 people interested in working AIGLX for XWin :-)
>>
>> I wouldn't suggest testing with those binaries at this stage, as I've 
>> moved on a bit.  I hope to shortly make another test release 
>> containing AIGLX based on the upcoming Xserver 1.9, and I would very 
>> much appreciate some testing of the AIGLX functionality in that, when it is available.
>>
>> [1] http://cygwin.com/cgi-bin2/package-grep.cgi?grep=xwin-gl

--
Jon TURNEY
Volunteer Cygwin/X X Server maintainer

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

Re: X hardware acceleration still flaky?

[Jon TURNEY]

On 09/08/2010 15:08, L.Wood@surrey.ac.uk wrote:
> Hi Jon,
>
> the lack of flickering and lack of double-buffering you describe sounds like geomview being run without opengl, either  because it has been compiled without opengl (still the default if you just type ./configure, I believe), or because
> geomview -noopengl
> was issued. Did you build Geomview with --with-opengl, and have you turned on a texturemapped Earth showing coloured continents? (If geomview issues a 'Shared memory unavailable, using fallback display method' to stderr at launch, it's not using OpenGL.)

Yes, I have configured geomview with --with-opengl.

No, I didn't turn on texturemapped earth, because your report didn't mention 
that. Does this mean turn on "Texture mapping" in Savi's rendering menu (which 
appears to be on by default) or "Use simple/detailed earth map"?

If I run geomview -noppengl I get no flickering even when rotating the planet.

> When geomview is run with opengl, I see consistent flickering at every single animation stage, not just when dragging with the mouse. -noopengl is much smoother. (I'm using a fairly high-end Core2Duo with graphic card.)

Do you have something to make an animation start automatically when savi 
opens? I just get a static planet and z,y,x axes unless I drag it around with 
the mouse.

> I've now realised that my crashes only occur when I use the second screen attached to my machine. (Mea culpa - I take multiple screens for granted.) When geomview's camera is on the root (laptop) screen, X doesn't crash, even when texturemapping, and I get slow but flickery animations of texturemapped Earths. Move it over to the second screen and do something that invokes texturemapping like turning on a detailed Earth - goodbye, Mr X.

I am also using multiple monitors.

> It's a little odd that XWin.0.log doesn't explicitly call out the two screens as such - it knows the primary (laptop) monitor is 1280 by 800, and that DIB has a height of 1824 because there's a 1280x1024 screen positioned above it.

Although the logging could perhaps be clearer, -multiwindow implies 
-multimonitors by default which gives a single X screen the size of the 
Windows virtual desktop.

> Is it still useful to give you a bt from gdb?

Yes, please.

-- 
Jon TURNEY
Volunteer Cygwin/X X Server maintainer

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

Re: X hardware acceleration still flaky?

[L.Wood]

On 9 Aug 2010, at 17:30, Jon TURNEY wrote:

> On 09/08/2010 15:08, L.Wood@surrey.ac.uk wrote:
>> Hi Jon,
>> 
>> the lack of flickering and lack of double-buffering you describe sounds like geomview being run without opengl, either  because it has been compiled without opengl (still the default if you just type ./configure, I believe), or because
>> geomview -noopengl
>> was issued. Did you build Geomview with --with-opengl, and have you turned on a texturemapped Earth showing coloured continents? (If geomview issues a 'Shared memory unavailable, using fallback display method' to stderr at launch, it's not using OpenGL.)
> 
> Yes, I have configured geomview with --with-opengl.
> 
> No, I didn't turn on texturemapped earth, because your report didn't mention 
> that. Does this mean turn on "Texture mapping" in Savi's rendering menu (which 
> appears to be on by default) or "Use simple/detailed earth map"?

Yes, my report didn't mention texturemapping; it wasn't needed for the crash. But, to stress things and see if a crash can be provoked, it's worth putting into operation.

Texturemapping is enabled by default, yes. But SaVi defaults to a blue sphere, because it can't be sure Geomview and the display support OpenGL or texturemapping, so by default doesn't try to do anything fancy with texturemapping. To turn on texturemapping turn on 'Use detailed Earth map'. That should then show colourful landmasses when texturemapping is enabled.

Opening the Coverage panel (Views menu/Global Coverage...) and turning on sending the coverage map to Geomview from the coverage panel's Rendering menu and then pressing >> in the animation bar (at the bottom of each window) to animate will force dynamic texturemapping and pipe the coverage maps to Geomview, so that Geomview's camera window is always updating. That's the best way I know of to stress texturemapping.

The reason for doing this - if this all works and we see a bitmap animating on the sphere, OpenGL and texturemapping are definitely working under stress/load. If we're only looking at a stationary default blue sphere, we can't really be sure what's working.

> If I run geomview -noppengl I get no flickering even when rotating the planet.
> 
>> When geomview is run with opengl, I see consistent flickering at every single animation stage, not just when dragging with the mouse. -noopengl is much smoother. (I'm using a fairly high-end Core2Duo with graphic card.)
> 
> Do you have something to make an animation start automatically when savi 
> opens? I just get a static planet and z,y,x axes unless I drag it around with 
> the mouse.

See instructions above. Once texturemapping is turned on and SaVi is sending coverage maps to Geomview to render, the load can be fairly large. You can select e.g. the Iridium constellation from the constellations menu so that there's a lot of visible animation. Pressing the >> button starts animating.

>> I've now realised that my crashes only occur when I use the second screen attached to my machine. (Mea culpa - I take multiple screens for granted.) When geomview's camera is on the root (laptop) screen, X doesn't crash, even when texturemapping, and I get slow but flickery animations of texturemapped Earths. Move it over to the second screen and do something that invokes texturemapping like turning on a detailed Earth - goodbye, Mr X.
> 
> I am also using multiple monitors.
> 
>> It's a little odd that XWin.0.log doesn't explicitly call out the two screens as such - it knows the primary (laptop) monitor is 1280 by 800, and that DIB has a height of 1824 because there's a 1280x1024 screen positioned above it.
> 
> Although the logging could perhaps be clearer, -multiwindow implies 
> -multimonitors by default which gives a single X screen the size of the 
> Windows virtual desktop.

okay, that much makes sense.

> 
>> Is it still useful to give you a bt from gdb?
> 
> Yes, please.

Right, thanks for gdb --pid= capture instructions in other mail; screengrabs of bt (if cygwin terminal supports copy and paste, I couldn't figure it out...) in private mail to you.


cheers,

L.

> 
> -- 
> Jon TURNEY
> Volunteer Cygwin/X X Server maintainer

Lloyd Wood
L.Wood@surrey.ac.uk
http://sat-net.com/L.Wood




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

Re: X hardware acceleration still flaky?

[Andy Koppe]

On 9 August 2010 19:12, L.Wood wrote:
> if cygwin terminal supports copy and paste, I couldn't figure it out...

Right click on titlebar, Edit->Mark, drag left mouse button to select,
right click to copy. Yep, it's terrible, but that's the standard
Windows console for you. Enable 'Quick Edit' in its properties to be
able to select without finding the Mark command first. Or use one of
the other terminals, with straightforward copy-on-select: mintty,
xterm, or rxvt(-unicode).

Andy

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

RE: X hardware acceleration still flaky?

[L.Wood]

> Right, thanks for gdb --pid= capture instructions in other mail;
> screengrabs of bt (if cygwin terminal supports copy and paste, I
> couldn't figure it out...)in private mail to you.

Thanks for the right-click title-bar hint, Andy.

And here's the backtrace text from Jon's XWin code drop at:
ftp://cygwin.com/pub/cygwinx/XWin.20100808-git-66f3680cb47fbd09.exe.bz2
crashing after I place geomview's camera window on my second screen:


Loaded symbols for /cygdrive/c/Windows/system32/msi.dll
Reading symbols from /cygdrive/c/Windows/system32/SFC.DLL...
warning: Lowest section in /cygdrive/c/Windows/system32/SFC.DLL is .text at 0040
1000
done.
Loaded symbols for /cygdrive/c/Windows/system32/SFC.DLL
Reading symbols from /cygdrive/c/Windows/system32/sfc_os.DLL...done.
Loaded symbols for /cygdrive/c/Windows/system32/sfc_os.DLL
[Switching to thread 5736.0x1a08]
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 5736.0x16c4]
0x6fb96c8d in pixman_fill_sse2 () from /usr/bin/cygpixman-1-0.dll
(gdb) bt
#0  0x6fb96c8d in pixman_fill_sse2 () from /usr/bin/cygpixman-1-0.dll
#1  0x6fb97205 in pixman_fill_sse2 () from /usr/bin/cygpixman-1-0.dll
#2  0x6fb77245 in pixman_fill () from /usr/bin/cygpixman-1-0.dll
#3  0x0044924b in fbFill (pDrawable=0x109306f8, pGC=0x10936530, x=657, y=367,
    width=450, height=450) at fbfill.c:48
#4  0x0044746f in fbPolyFillRect (pDrawable=0x109306f8, pGC=0x10936530,
    nrect=0, prect=0x1096791c) at fbfillrect.c:77
#5  0x0052728f in damagePolyFillRect (pDrawable=0x109306f8, pGC=0x10936530,
    nRects=1, pRects=0x10967914) at damage.c:1404
#6  0x005504c3 in ProcPolyFillRectangle (client=0x106bd4f0) at dispatch.c:1939
#7  0x0054c56e in Dispatch () at dispatch.c:439
#8  0x005465af in main (argc=3, argv=0x61227b64, envp=0x104300f8)
    at main.c:286
(gdb) c
Continuing.

Program exited with code 0400.
(gdb)

cheers,

L.

SaVi satellite constellation visualization http://savi.sf.net/ 




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

Re: X hardware acceleration still flaky?

[Jon TURNEY]

On 10/08/2010 12:00, L.Wood@surrey.ac.uk wrote:
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to thread 5736.0x16c4]
> 0x6fb96c8d in pixman_fill_sse2 () from /usr/bin/cygpixman-1-0.dll
> (gdb) bt
> #0  0x6fb96c8d in pixman_fill_sse2 () from /usr/bin/cygpixman-1-0.dll
> #1  0x6fb97205 in pixman_fill_sse2 () from /usr/bin/cygpixman-1-0.dll
> #2  0x6fb77245 in pixman_fill () from /usr/bin/cygpixman-1-0.dll
> #3  0x0044924b in fbFill (pDrawable=0x109306f8, pGC=0x10936530, x=657, y=367,
>      width=450, height=450) at fbfill.c:48
> #4  0x0044746f in fbPolyFillRect (pDrawable=0x109306f8, pGC=0x10936530,
>      nrect=0, prect=0x1096791c) at fbfillrect.c:77
> #5  0x0052728f in damagePolyFillRect (pDrawable=0x109306f8, pGC=0x10936530,
>      nRects=1, pRects=0x10967914) at damage.c:1404
> #6  0x005504c3 in ProcPolyFillRectangle (client=0x106bd4f0) at dispatch.c:1939
> #7  0x0054c56e in Dispatch () at dispatch.c:439
> #8  0x005465af in main (argc=3, argv=0x61227b64, envp=0x104300f8)
>      at main.c:286

Thanks.

With the details provided in the last couple of emails, I have managed to 
reproduce what I think is the same problem as you are seeing.

1) Start geomview
2) Cause the geomview camera window to start animating, e.g. by loading one of 
the demo scenes and making the camera rotate, or by opening SaVi and starting 
simulated time running
3) Move the camera window away from it's original position up or to the left 
(observe if you move it a small amount to the right or down, the area of scene 
being drawn in it which is updated is constrained to the original window position)

This has nothing to do with 'hardware acceleration' or OpenGL, it seems that 
the particular way this application draws it's output (into a same-size child 
window of the camera window) interacts with the composite extension to expose 
a bug in the XWin code.

You should be able to workaround the crash by starting the X server with 
'-extension Composite' to disable the composite extension.

I've uploaded a build with an attempt at fixing this at [1].  Perhaps you 
could try it out and see if it works for you?

I'm not sure why the image flickers so badly, a double buffered OpenGL visual 
seems to be being used, so only a complete frame should be transferred to the 
display, but I can see elements of the scene being drawn.

[1] ftp://cygwin.com/pub/cygwinx/XWin.20100812-git-7180c693de178032.exe.bz2

-- 
Jon TURNEY
Volunteer Cygwin/X X Server maintainer

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

RE: X hardware acceleration still flaky?

[L.Wood]

Jon,

thanks for looking into this.

I can confirm that under the current Cygwin release, with your original XWin debug code and geomview running with opengl support enabled and SaVi animating the Geomview window and forcing camera updates:
moving the geomview window up and/or to the left causes the crash,
while moving it down and/or to the left constrains the updated area to the overlap of the current window position with the original viewport (if that's the right term) - hard to spot amongst the flickering, and I missed that. Apologies.

So, yes, it's not related to use of a second monitor; I was moving the geomview camera up to that monitor to get the crash.

I can confirm that your replacement code drop (url below) appears to fix this crash problem.

However, I have a question about your conclusion that this has nothing to do with opengl.

If you start geomview under a buggy crashing XWin server with:
geomview -noopengl (one dash, note spelling)
there's no flickering or crashing; drawing is always slow and reliable, even under a buggy XWin. From that, it's a pretty easy conclusion to presume that OpenGL is somehow involved? Or is only one of the geomview drawing methods (the one that just happens to use OpenGL) at fault with the composite extension?

somewhat enlightened but also somewhat puzzled,

thanks,

L.

SaVi satellite constellation visualization: http://savi.sf.net/ 

-----Original Message-----
From: Jon TURNEY [mailto:jon.turney@dronecode.org.uk] 
Sent: 12 August 2010 18:51
To: cygwin-xfree@cygwin.com
Cc: Wood L Dr (Electronic Eng)
Subject: Re: X hardware acceleration still flaky?
Importance: High

On 10/08/2010 12:00, L.Wood@surrey.ac.uk wrote:
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to thread 5736.0x16c4]
> 0x6fb96c8d in pixman_fill_sse2 () from /usr/bin/cygpixman-1-0.dll
> (gdb) bt
> #0  0x6fb96c8d in pixman_fill_sse2 () from /usr/bin/cygpixman-1-0.dll
> #1  0x6fb97205 in pixman_fill_sse2 () from /usr/bin/cygpixman-1-0.dll
> #2  0x6fb77245 in pixman_fill () from /usr/bin/cygpixman-1-0.dll
> #3  0x0044924b in fbFill (pDrawable=0x109306f8, pGC=0x10936530, x=657, y=367,
>      width=450, height=450) at fbfill.c:48
> #4  0x0044746f in fbPolyFillRect (pDrawable=0x109306f8, pGC=0x10936530,
>      nrect=0, prect=0x1096791c) at fbfillrect.c:77
> #5  0x0052728f in damagePolyFillRect (pDrawable=0x109306f8, pGC=0x10936530,
>      nRects=1, pRects=0x10967914) at damage.c:1404
> #6  0x005504c3 in ProcPolyFillRectangle (client=0x106bd4f0) at 
> dispatch.c:1939
> #7  0x0054c56e in Dispatch () at dispatch.c:439
> #8  0x005465af in main (argc=3, argv=0x61227b64, envp=0x104300f8)
>      at main.c:286

Thanks.

With the details provided in the last couple of emails, I have managed to reproduce what I think is the same problem as you are seeing.

1) Start geomview
2) Cause the geomview camera window to start animating, e.g. by loading one of the demo scenes and making the camera rotate, or by opening SaVi and starting simulated time running
3) Move the camera window away from it's original position up or to the left (observe if you move it a small amount to the right or down, the area of scene being drawn in it which is updated is constrained to the original window position)

This has nothing to do with 'hardware acceleration' or OpenGL, it seems that the particular way this application draws it's output (into a same-size child window of the camera window) interacts with the composite extension to expose a bug in the XWin code.

You should be able to workaround the crash by starting the X server with '-extension Composite' to disable the composite extension.

I've uploaded a build with an attempt at fixing this at [1].  Perhaps you could try it out and see if it works for you?

I'm not sure why the image flickers so badly, a double buffered OpenGL visual seems to be being used, so only a complete frame should be transferred to the display, but I can see elements of the scene being drawn.

[1] ftp://cygwin.com/pub/cygwinx/XWin.20100812-git-7180c693de178032.exe.bz2

--
Jon TURNEY
Volunteer Cygwin/X X Server maintainer

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

Re: X hardware acceleration still flaky?

[Jon TURNEY]

On 12/08/2010 19:20, L.Wood@surrey.ac.uk wrote:
> I can confirm that under the current Cygwin release, with your original XWin debug code and geomview running with opengl support enabled and SaVi animating the Geomview window and forcing camera updates:
> moving the geomview window up and/or to the left causes the crash,
> while moving it down and/or to the left constrains the updated area to the overlap of the current window position with the original viewport (if that's the right term) - hard to spot amongst the flickering, and I missed that. Apologies.
>
> So, yes, it's not related to use of a second monitor; I was moving the geomview camera up to that monitor to get the crash.
>
> I can confirm that your replacement code drop (url below) appears to fix this crash problem.

Thanks for testing.

> However, I have a question about your conclusion that this has nothing to do with opengl.
>
> If you start geomview under a buggy crashing XWin server with:
> geomview -noopengl (one dash, note spelling)
> there's no flickering or crashing; drawing is always slow and reliable, even under a buggy XWin. From that, it's a pretty easy conclusion to presume that OpenGL is somehow involved? Or is only one of the geomview drawing methods (the one that just happens to use OpenGL) at fault with the composite extension?

Whilst this is the obvious conclusion to reach, it doesn't seem to be correct.

Supplying -noopengl to geomview causes it to do different things, and in 
particular, it creates a different window hierarchy inside the camera window
(which you can observe using xwininfo -tree on that camera window).  It seems 
that the window hierarchy used when opengl is selected, happens to expose a 
bug in XWin, which causes composite to handle the window's position incorrectly.

-- 
Jon TURNEY
Volunteer Cygwin/X X Server maintainer

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/