Cygwin's current libGL is built --with-driver=x11, but the code to use GLX in that driver looks like it's been disabled/unmaintained since 2005, so it *always* uses client-side swrast and transfers the image using xlib, and there is no option to make it use indirect (server-side) rendering. Attached patch (against cygports svn) makes it possible to build a Cygwin libGL --with-driver=dri --with-dri-driver=swrast, so that LIBGL_ALWAYS_INDIRECT can be used to request indirect (server-side) rendering, and thus can be accelerated. This is a pre-requisite for useful AIGLX in the server. Without LIBGL_ALWAYS_INDIRECT being set, this library should behave exactly as before. However, I have seen problems with the X server after loading cygGL-1.dll and swrast_dri.so built like this, which causes it to spin whilst forking to start xkbcomp, so something is not quite right somewhere... For reasons I haven't investigated, libOSMesa fails to build in this configuration.
Created attachment 4104 [details] Patch for mesa to enable it to be built with indirect rendering
Created attachment 4126 [details] Patch to add AIGLX using native WGL Patch generated using 'git diff cygwin-patches-1.6..HEAD' on the branch cygwin-aiglx on my fd.o git tree (http://cgit.freedesktop.org/~jturney/xserver/?h=cygwin-aiglx) This add a GLX provider using native WGL for hardware acceleration. Most of the changes should be passive unless the new '-wgl' option is used to enable the new GLX provider. It would be great if you could review the hopefully small and non-invasive changes which aren't passive (i.e. the stuff outside of indirect/glwrap/wgl_ext_api) so we might consider adding this patch to expose AIGLX for wider testing without destabilizing things too much.
Created attachment 4350 [details] Patch to add AIGLX using native WGL Patch rebased and updated for xserver 1.7
Any updates here? Is there a chance of getting this in for 1.8?
(In reply to comment #4) > Any updates here? Is there a chance of getting this in for 1.8? I'm not sure if this rebases ok onto git master. I've had zero feedback on this so far, so I'd like a little bit more testing. To facilitate that, I was thinking it might be useful to do a test release available via setup.
Created attachment 4629 [details] Patch for mesa to enable it to be built with indirect rendering Updated mesa patch for mesa 7.6.1
Created attachment 4634 [details] Patch to add AIGLX using native WGL Xserver patch rebased for git master. Patch generated using 'git diff master..HEAD^' on the branch cygwin-aiglx-for-master on my fd.o git tree
Created attachment 4670 [details] Patch to add AIGLX using native WGL Actually attach the correct, updated version of the patch.
Congrats on getting this into master. Is the Mesa patch still the same, and does this obsolete the "Cygwin/X: GLX crash workaround" patch?
I have ported this to the latest Mesa release (7.8.2), and with xorg-server-1.9.0-1 -wgl and LIBGL_ALWAYS_INDIRECT=1 I apparently got this working (glxinfo reports my video card, glxgears shows much-increased FPS). libOSMesa defaults to disabled when using DRI driver instead of Xlib, and as nothing that I know of requires it, I'll just leave it disabled for now. Please test: ftp://ftp.cygwinports.org/pub/cygwinports/uploads/X.Org/mesa/ http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/ports;a=tree;f=x11/mesa
In the interest of one less thing for the user to configure, it might makes sense to configure --disable-driglx-direct, which mean we build a libGL which only supports indirect rendering (or even make that the default on cygwin), as offering direct when we only have swrast is pretty pointless.
(In reply to comment #10) > Please test: > > ftp://ftp.cygwinports.org/pub/cygwinports/uploads/X.Org/mesa/ > > http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/ports;a=tree;f=x11/mesa Tried this with various OpenGL tests and apps today, seems to work ok. You can drop the hunk about dxtn.dll, that's wrong (although it doesn't work for a different reason) Can you include my first patch from https://bugs.freedesktop.org/show_bug.cgi?id=30102. With that I can run the glean test suite completely (there are some failures which seem to be due to the limitations of the underlying windows driver or my graphics card hardware)
Created attachment 5041 [details] comparison of SWRAST to WGL Even after your 'window-sizing-fix', with WGL only, OpenGL window dimensions are correct but the graphics are displayed from the upper-left corner of the window decoration instead of the window frame. The attached screenshot shows two instances of glxheads run against two instances of the 'window-sizing-fix' server, where :0 was run without WGL and :1 with WGL.
Created attachment 5042 [details] Cygwin DRI patch (take 3) (In reply to comment #11) > In the interest of one less thing for the user to configure, it might makes > sense to configure --disable-driglx-direct, which mean we build a libGL which > only supports indirect rendering (or even make that the default on cygwin), as > offering direct when we only have swrast is pretty pointless. Dropping direct rendering makes for a much simpler patch; attached. Note that this does not require the --disable-driglx-direct flag.
New build with this patch uploaded to same location: ftp://ftp.cygwinports.org/pub/cygwinports/uploads/X.Org/mesa/ This build does not require setting LIBGL_ALWAYS_INDIRECT.
(In reply to comment #15) > New build with this patch uploaded to same location: > > ftp://ftp.cygwinports.org/pub/cygwinports/uploads/X.Org/mesa/ > > This build does not require setting LIBGL_ALWAYS_INDIRECT. WFM.
(In reply to comment #13) > Created attachment 5041 [details] > comparison of SWRAST to WGL > > Even after your 'window-sizing-fix', with WGL only, OpenGL window dimensions > are correct but the graphics are displayed from the upper-left corner of the > window decoration instead of the window frame. > > The attached screenshot shows two instances of glxheads run against two > instances of the 'window-sizing-fix' server, where :0 was run without WGL and > :1 with WGL. I can't reproduce that. If it still exists with the latest changes, can you please: - build Xserver ./configured with --enable-debug - export WIN_DEBUG_MESSAGES=1 - add '-wgl -noclipboard -logverbose 3' xserver options - attach the XWin logfile you get when running glxheads
Created attachment 5045 [details] XWin log (In reply to comment #17) > I can't reproduce that. If it still exists with the latest changes, can you > please: > > - build Xserver ./configured with --enable-debug > - export WIN_DEBUG_MESSAGES=1 > - add '-wgl -noclipboard -logverbose 3' xserver options > - attach the XWin logfile you get when running glxheads Attached.
Something else: while simple OpenGL programs (e.g. those that ship with Mesa) work fine with WGL, GTK+/GNOME and Qt/KDE OpenGL programs never display their OpenGL-drawn contents. Other parts of the program display and operate correctly (e.g. menu bars). The examples from the gtkglext source package and qt4-qtdemo show this.
(In reply to comment #18) > Created attachment 5045 [details] > XWin log > > (In reply to comment #17) > > I can't reproduce that. If it still exists with the latest changes, can you > > please: > > > > - build Xserver ./configured with --enable-debug > > - export WIN_DEBUG_MESSAGES=1 > > - add '-wgl -noclipboard -logverbose 3' xserver options > > - attach the XWin logfile you get when running glxheads > > Attached. Thanks. Can you run that again with 'export GLWIN_DEBUG_ALL=1' as well?
Created attachment 5046 [details] XWin log with GLWIN_DEBUG_ALL (In reply to comment #20) > Thanks. Can you run that again with 'export GLWIN_DEBUG_ALL=1' as well? Attached.
For the record: <jturney> cygwinports: just to be clear, what happens when you move the glxheads window which is misrendered <jturney> does the GL drawing stay offset in the same position relative to the window? <cygwinports> jturney: yes <cygwinports> its probably a wgl issue, not a window sizing issue <jturney> yeah, I'm thinking it's going to be aero DWM related <cygwinports> oh, lovely <cygwinports> i'll try shutting down aero <cygwinports> and sure enough, you're right! <jturney> there are all kinds of wrinkles to using opengl on aero <cygwinports> so I see... <jturney> I'll have a read and see what we are doing wrong :-)
(In reply to comment #22) > For the record: > > <jturney> cygwinports: just to be clear, what happens when you move the > glxheads window which is misrendered > <jturney> does the GL drawing stay offset in the same position relative to the > window? > <cygwinports> jturney: yes What happens to the GL viewport when you move the window?
(In reply to comment #23) > (In reply to comment #22) > > For the record: > > > > <jturney> cygwinports: just to be clear, what happens when you move the > > glxheads window which is misrendered > > <jturney> does the GL drawing stay offset in the same position relative to the > > window? > > <cygwinports> jturney: yes > > What happens to the GL viewport when you move the window? Doh! "What happens to the GL viewport when you *resize* the window?" is what I meant to ask...
(In reply to comment #19) > Something else: while simple OpenGL programs (e.g. those that ship with Mesa) > work fine with WGL, GTK+/GNOME and Qt/KDE OpenGL programs never display their > OpenGL-drawn contents. Other parts of the program display and operate > correctly (e.g. menu bars). The examples from the gtkglext source package and > qt4-qtdemo show this. Oh my. The case where the OpenGL window isn't a top-level window isn't even considered, so that is only going to work by pure chance at the moment. This is a rather large chunk of missing functionality.
(In reply to comment #24) > Doh! "What happens to the GL viewport when you *resize* the window?" is what I > meant to ask... The viewport resizes appropriately but its incorrect geometry remains.
(In reply to comment #26) > (In reply to comment #24) > > Doh! "What happens to the GL viewport when you *resize* the window?" is what I > > meant to ask... > > The viewport resizes appropriately but its incorrect geometry remains. In your case, it looks like the aero compositor isn't updating the origin of GL viewport when the window style changes I tried to reproduce this on W7 without luck, although that was on a ATOM/Nvidia Ion system. It could be that this is a timing condition, whcih is why I can't see it, or it might be that this is a driver issue. I've pushed a branch 'cygwin-release-1.9-fixes' which contains a hacky fix, which should test the theory about the cause.
(In reply to comment #27) > In your case, it looks like the aero compositor isn't updating the origin of GL > viewport when the window style changes > > I tried to reproduce this on W7 without luck, although that was on a > ATOM/Nvidia Ion system. It could be that this is a timing condition, whcih is > why I can't see it, or it might be that this is a driver issue. I wish you had suggested that earlier. I updated my display card drivers and now the offset problem is gone, so this was indeed a driver issue. We should make sure to add to the documentation that display drivers should be updated from the manufacturer before reporting any issues with WGL. Non-top-level windows still do not display, but from your comment, I gather that's not surprising. How much more work is that going to be?
(In reply to comment #28) > (In reply to comment #27) > > In your case, it looks like the aero compositor isn't updating the origin of GL > > viewport when the window style changes > > > > I tried to reproduce this on W7 without luck, although that was on a > > ATOM/Nvidia Ion system. It could be that this is a timing condition, whcih is > > why I can't see it, or it might be that this is a driver issue. > > I wish you had suggested that earlier. I updated my display card drivers and > now the offset problem is gone, so this was indeed a driver issue. We should > make sure to add to the documentation that display drivers should be updated > from the manufacturer before reporting any issues with WGL. I wish I'd thought of it earlier :-) Anyhow, this is good, as working around the problem would have been horrible. > Non-top-level windows still do not display, but from your comment, I gather > that's not surprising. How much more work is that going to be? I'm not even sure how to do it yet. Currently I'm thinking that I'll need to create Windows windows to match the X window hierarchy, so that a Windows window exists with the correct geometry to do the OpenGL drawing into. None of this existed in the XWin_GL implementation, so I guess it had the same shortcoming. The good thing is that this would give a way to make AIGLX work in windowed X server modes as well. I'm probably not going to get a block of time to work on this for a while, so I don't think it's worth holding the Xserver 1.9.0 release up for (assuming I fix the window placement issues with that) While WGL may not be very useful for actual work with this limitation, it may at least be tested a bit.
(In reply to comment #29) > I'm probably not going to get a block of time to work on this for a while, > so I don't think it's worth holding the Xserver 1.9.0 release up for > (assuming I fix the window placement issues with that) You mean 1.9.1, which will be out Friday? > While WGL may not be very useful for actual work with this limitation, it may > at least be tested a bit. Agreed.
Let's put this here where I should have in the first place :-) On 01/11/2010 04:33, Yaakov (Cygwin/X) wrote: > On Sun, 2010-10-31 at 20:31 +0000, Jon TURNEY wrote: >> It would be great if you could give this a quick test. If there are no >> obvious problems I'll push this out as 1.9.1-1 sometime this week. > >> - framebufferobject2 looks like it might not be working properly, no idea why >> or what it's supposed to look like when working properly > > It has that same offset problem that I had with all WGL windows before > upgrading my drivers. I just get some white cubes bouncing on a gray background, which doesn't look right, so maybe that's my graphics card being rubbish. >> - It looks like OpenGL rendering just 'punches through' applications which use >> layered windows for translucency e.g mintty, at least on XP. > > Ditto for Win7. > > Further issues found with WGL which don't occur with swrast: > > * ksudoku (3D-mode): grab-and-rotates aren't displayed smoothly. I can't reproduce this, 3d grab-and-rotate seems quite fluid (although some random KDE stuff starts up in the background which doesn't help) ksudoku or some kde library needs a a dependency on dbus, btw :-) > * stellarium: crashes on startup (QGLContext::makeCurrent(): Failed.) This was caused by the OpenGL window being reparented to an unmapped window. I've pushed a patch to my snapshot branch which fixes that and allows this to startup and draw the sky. Still has a few problems though: The configuration dialog boxes are heavily pixellated for some reason. When cygserver is running so the X server has the MIT-SHM extension, lots of X errors relating to MIT-SHM are reported.
(In reply to comment #31) > I can't reproduce this, 3d grab-and-rotate seems quite fluid (although some > random KDE stuff starts up in the background which doesn't help) It helps to manually launch kdeinit4 and give it a minute to do its thing before trying to start a KDE program. Nevertheless, KDE programs do tend to be a bit more sluggish than their GNOME counterparts, probably due to all the IPC involved. > ksudoku or some kde library needs a a dependency on dbus, btw :-) You can't run much desktop software without dbus these days -- not that that's a bad thing, it sure beats ORBit or DCOP. However it should have been pulled in as a dependency; I'll have to look into that. > > * stellarium: crashes on startup (QGLContext::makeCurrent(): Failed.) > > This was caused by the OpenGL window being reparented to an unmapped window. > I've pushed a patch to my snapshot branch which fixes that and allows this to > startup and draw the sky. > > Still has a few problems though: The configuration dialog boxes are heavily > pixellated for some reason. When cygserver is running so the X server has the > MIT-SHM extension, lots of X errors relating to MIT-SHM are reported. The dialogs are pixalated even without WGL, so something else is going wrong there.
1) Have we gotten any useful feedback on -multiwindow -wgl? Do you think we should make it the default? 2) What needs to be done to add acceleration to windowed mode?
(In reply to comment #33) > 1) Have we gotten any useful feedback on -multiwindow -wgl? Do you think we > should make it the default? Feedback has been pretty limited, there were a few problems reported which I think I've fixed. So, yes, I think that we should make -wgl (and probably -resize as well) on by default. Let's try to do that before 1.12.0 > 2) What needs to be done to add acceleration to windowed mode? Basically, what is needed is to use the same trick as is used from non-toplevel windows in multiwindow mode i.e. create a native window hierarchy which matches the X window hierarchy, so that the GL drawing can take place to a correctly sized and positioned window.
Created attachment 6137 [details] Patch for cygwin-release-1.11 (In reply to comment #34) > (In reply to comment #33) > > 1) Have we gotten any useful feedback on -multiwindow -wgl? Do you think we > > should make it the default? > > Feedback has been pretty limited, there were a few problems reported which I > think I've fixed. > > So, yes, I think that we should make -wgl (and probably -resize as well) on by > default. Let's try to do that before 1.12.0 Patch attached.
(In reply to comment #34) > (and probably -resize as well) on by default. You mean -resize=randr?
(In reply to comment #35) > Created attachment 6137 [details] > Patch for cygwin-release-1.11 > > Patch attached. Thanks. (In reply to comment #36) > (In reply to comment #34) > > (and probably -resize as well) on by default. > > You mean -resize=randr? Yes, that's what I meant, they should be equivalent as according to man XWin "-resize on its own is equivalent to -resize=randr"
Created attachment 6195 [details] AIGLX in windowed mode > > 2) What needs to be done to add acceleration to windowed mode? > > Basically, what is needed is to use the same trick as is used from non-toplevel > windows in multiwindow mode i.e. create a native window hierarchy which matches > the X window hierarchy, so that the GL drawing can take place to a correctly > sized and positioned window. Attached is a first cut at windowed mode AIGLX (this should be applied on top of xserver-cygwin-1.11.4), based on some code that is in Xming. However, from some quick testing, I can see a problem: If I run 2 glxheads and move them so one occludes the other, they race to draw on top of each other. The Z-order of these OpenGL child windows doesn't track the native windows Z-order, and even if we did that, I'm not sure that occlusion would occur (I'm not sure if our use of WS_EX_TRANSPARENT makes any difference to GL rendering) (I think at least this second problem also exists if we have multiple non-toplevel GL windows inside a single top-level window in multiwindowed mode)
(In reply to comment #38) > Attached is a first cut at windowed mode AIGLX (this should be applied on top > of xserver-cygwin-1.11.4), based on some code that is in Xming. Thank you for looking into this. > However, from some quick testing, I can see a problem: If I run 2 glxheads and > move them so one occludes the other, they race to draw on top of each other. > > The Z-order of these OpenGL child windows doesn't track the native windows > Z-order, and even if we did that, I'm not sure that occlusion would occur (I'm > not sure if our use of WS_EX_TRANSPARENT makes any difference to GL rendering) > > (I think at least this second problem also exists if we have multiple > non-toplevel GL windows inside a single top-level window in multiwindowed mode) Some quick testing revealed the following: * even simple GL windows (e.g. glxgears) appear before their window decoration * a non-toplevel GL window seems only to render when the top-level window containing it is active; switching active windows causes the GL window to go blank. * Compositing effects (e.g. shading around drop-down menus) are treated as opaque. * In quadrapassel (gnome-games' Tetris clone), moving a falling piece all the way to one side causes the GL window to blink. Once this happens, moving that or other pieces to the same side does not repeat it, but to the opposite side causes another blink, and the same rule then applies to that side. * mutter (a Clutter-based WM used by gnome-shell) doesn't work properly (the entire screen is blank) * GLX_EXT_texture_from_pixmap is apparently missing (required by gnome-shell)
Further observations: * If I switch virtual desktops while glxgears is running, the GL window still shows on the newly selected virtual desktop, but without the WM decoration. This does not happen with clutter apps (whose GL windows usually go blank when the parent is inactive). * When moving a glxgears window, the GL window continues to work as it is moved, but still "echos" are left behind until the window is still (even if the grab has not been released). But with sushi (the Nautilus file previewer, which does not take a WM decoration), whatever was beneath the sushi window when it *first* appeared is what is seen while dragging, even by subsequent drags.
(In reply to comment #39) Thanks for trying this out. I've pushed some updated code to the windowed-mode-aiglx branch of my tree on fd.o, but I'm not sure you're going to be impressed. > * Compositing effects (e.g. shading around drop-down menus) are treated as > opaque. Anything that is drawn with OpenGL isn't composed into the screen, it's just drawn on top of it. Well, in fact not even that was reliably happening, so sometimes we ended with the corresponding part of the framebuffer (often blank) visible instead. I've don't a bit of fixing so the GL drawing being on top is more reliable, which looks ok most of the time in multiwindow mode, but not so much so in windowed mode. However, this is just fiddling around the edges, the proper solution to this is to render GL offscreen, and then compose it in, and I guess we are going to have to bite the bullet on that at some stage, but I think it would be logical to work on the simpler task of native composing in multiwindow mode first... > * a non-toplevel GL window seems only to render when the top-level window > containing it is active; switching active windows causes the GL window to go > blank. This seems to be because redrawing the window with an inactive frame was drawing the framebuffer over the GL drawing. I've tweaked things so we ask the GL window to draw itself again after this, so it should appear on top. > * GLX_EXT_texture_from_pixmap is apparently missing (required by gnome-shell) (In reply to comment #40) GLX_EXT_texture_from_pixmap isn't implemented at the moment. This is non-trivial as there isn't a directly equivalent WGL extension. I think this could be implemented in terms of WGL_ARB_render_texture, but that would require copying the texture into a pbuffer we internally manage. > * If I switch virtual desktops while glxgears is running, the GL window still > shows on the newly selected virtual desktop, but without the WM decoration. > This does not happen with clutter apps (whose GL windows usually go blank when > the parent is inactive). I think this is due to nothing being done to the GL native window when the X window is unmapped, which I've fixed. > * even simple GL windows (e.g. glxgears) appear before their window decoration I guess this is because we decided to be lazy and only make child windows for the GL window, not for the entire hierarchy containing it, so when the GL window gets mapped, we switch it to visible, rather than waiting until the hierarchy containing it (topped by the window manager frame containing the window decorations) is mapped. Assuming this guess is correct, that shouldn't be too hard to fix, but isn't fixed yet.
(In reply to comment #41) > Thanks for trying this out. I've pushed some updated code to the > windowed-mode-aiglx branch of my tree on fd.o, but I'm not sure you're going to > be impressed. Don't worry, I really didn't expect gnome-shell to work right now; I was just throwing everything I possibly could at it to see where we were at. Running your windowed-mode-aiglx branch as of this moment, here's what I found so far: * GL windows are stacked above menus and other non-GL windows, even when they are active and should be on top. * glxgears: GL window still appears before WM decoration. When moved, WM decoration remains in previous location until movement stops, and the GL window still leaves an "echo" trail. * lightsoff: GL window flickers when window is moved and when window is made in/active. * quadrapassel: ditto, and also when falling piece is moved to one side or another, as before. Menus end up beneath the GL windows. * ksudoku (3D mode): grid does not rotate smoothly. Menus also end up beneath GL windows. * mplayer -vo gl: crashes; I'll try to investigate. * sushi: same as lightsoff. > GLX_EXT_texture_from_pixmap isn't implemented at the moment. This is > non-trivial as there isn't a directly equivalent WGL extension. I think > this could be implemented in terms of WGL_ARB_render_texture, but that would > require copying the texture into a pbuffer we internally manage. This can wait for later.
I hate to mention this, after all the work you've put into this, but... IIUC, with xorg-server-1.12 and mesa-8.0, llvmpipe has been improved to the point where it should run gnome-shell and other GL-dependent desktops, for example: https://fedoraproject.org/wiki/Features/Gnome_shell_software_rendering *Realistically*, how far out is a working desktop AIGLX? Does it make sense to focus on getting this working in the meantime?