[opensuse-factory] When was it decided to stop supporting remote desktops?
It seems that's what has happened. When the dri drivers went into the X server, the removed the Xgl (or was it Xglx) extension that allowed OpenGL to be encapsulated in X. This meant you could have a server with lots of resources to do computations that would use a remote computer with a high end graphics card on any platform that supported X (BSD, MacOS, Windows (xp to win7) as well as desktop linux clients that don't have the same resources as a server. FWIW, the server wasn't built with available power supplies to even begin to support high end graphics cards these days. It seems also that this is the reason why XDMCP no longer works -- it was another remote desktop facility that would have needed the Xgl to transport most of today's desktop managers that use graphics acceleration to enable faster desktop respond with fancier effects. OpenGL *used* to work remotely on openSuse. Not anymore -- it seems that no form of remote testing or forwarding a remote desktop has been done for the past few cycles. I am biased in that I wanted to be able to use such occasionally -- maybe more so with an upgraded network. Was it actually planned, or did RedHat just kill it and other vendors followed suit because they went with the dri solution? The wayland support also doesn't seem to have an X-compat solution for 3D either. I'm not sure how possible or easy it would be, but it might be possible to get a degraded performance with a virtualGL solution that was designed to send the rendering commands to a 3rd computer that just did rendering and display the result to the client using the equivalent of jpeg/mpeg compression over slower networks, but possibly uncompressed over faster networks coming down the line. If the user has a 1Gb ethernet -- not unreasonable, they would have a max of about a max theoretical around 0.12GB which is about 7 frames/second if you try to send full screens, it would be hard to compress and uncompress that in SW to make it faster. But if you are just sending the rendering commands, it's like the difference between SVG and bitmapped graphics. The latter is 100's to 1000's times larger. Some of the largest SVG's I've seen have still been under 1MB, vs. bitmapped tiff's ... I've seen a few too many 4+GB that take a long time to read or write even over 1Gb. I'm guessing this wasn't intentional (??I hope), but that not many people realized what was happening until some time after the fact?? Is breaking remote compatibility with the past 15+ years a good thing? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2014-03-18 09:43, Linda Walsh wrote:
When the dri drivers went into the X server, the removed the Xgl (or was it Xglx) extension that allowed OpenGL to be encapsulated in X.
Did they? `ssh -Y localhost glxgears` still does its job (in 13.1). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jan Engelhardt wrote:
On Tuesday 2014-03-18 09:43, Linda Walsh wrote:
When the dri drivers went into the X server, the removed the Xgl (or was it Xglx) extension that allowed OpenGL to be encapsulated in X.
Did they? `ssh -Y localhost glxgears` still does its job (in 13.1).
---- You joker! That's because glx is configured to go around 'X' and directly to localhost...so of course ssh'ing into your own machine would work (providing your own machine can run glx)... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Linda Walsh wrote:
Jan Engelhardt wrote:
On Tuesday 2014-03-18 09:43, Linda Walsh wrote:
When the dri drivers went into the X server, the removed the Xgl (or was it Xglx) extension that allowed OpenGL to be encapsulated in X.
Did they? `ssh -Y localhost glxgears` still does its job (in 13.1).
---- You joker!
That's because glx is configured to go around 'X' and directly to localhost...so of course ssh'ing into your own machine would work (providing your own machine can run glx)...
Running "ssh -X <remote> glxgears" works for me from a 12.3 onto a 13.1 system. I get about 4fps over wifi. -- Per Jessen, Zürich (14.2°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Per Jessen wrote:
Running "ssh -X <remote> glxgears" works for me from a 12.3 onto a 13.1 system. I get about 4fps over wifi.
export LIBGL_DEBUG=verbose ssh -X ishtar glxgears
---- I get > ssh -X ishtar glxgears libGL error: failed to load driver: swrast libGL error: Try again with LIBGL_DEBUG=verbose for more details. then: Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 46362 frames in 28.2 seconds = 1645.590 FPS ---- Then: libGL error: failed to load driver: swrast libGL error: Try again with LIBGL_DEBUG=verbose for more details. I'm not sure what the 1st is... but the 2nd is in line with what I used to get. I get an X window, on my screen, but nothing in it and no indication that I'm receiving any thing over ~ 100k average... mostly around 30k occasional jump to 400, then 30 again.... --- I noted that Mesa can't be build with DRI and Xlib-GLX: running configure on Mesa 10.0.1 sources, I get: configure: error: DRI and Xlib-GLX cannot be built together Maybe your 13.1 machine has some old libraries around? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2014-03-18 12:27, Linda Walsh wrote:
Running "ssh -X <remote> glxgears" works for me from a 12.3 onto a 13.1 system. I get about 4fps over wifi.
I get > ssh -X ishtar glxgears libGL error: failed to load driver: swrast libGL error: Try again with LIBGL_DEBUG=verbose for more details. then:
Use LIBGL_DEBUG to find out. If swrast can't be loaded, bets are out of the window you'll get meaningful program behavior. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Linda Walsh wrote:
Per Jessen wrote:
Running "ssh -X <remote> glxgears" works for me from a 12.3 onto a 13.1 system. I get about 4fps over wifi.
----
I get > ssh -X ishtar glxgears libGL error: failed to load driver: swrast
I had a failure to load i965: libGL: OpenDriver: trying /usr/lib/dri/updates/tls/i965_dri.so libGL: OpenDriver: trying /usr/lib/dri/updates/i965_dri.so libGL error: dlopen /usr/lib/dri/updates/i965_dri.so failed (/usr/lib/dri/updates/i965_dri.so: cannot open shared object file: No such file or directory) libGL: OpenDriver: trying /usr/lib/dri/tls/i965_dri.so libGL: OpenDriver: trying /usr/lib/dri/i965_dri.so libGL error: failed to authenticate magic 4 libGL error: failed to load driver: i965 libGL: OpenDriver: trying /usr/lib/dri/updates/tls/swrast_dri.so libGL: OpenDriver: trying /usr/lib/dri/updates/swrast_dri.so libGL error: dlopen /usr/lib/dri/updates/swrast_dri.so failed (/usr/lib/dri/updates/swrast_dri.so: cannot open shared object file: No such file or directory) libGL: OpenDriver: trying /usr/lib/dri/tls/swrast_dri.so libGL: OpenDriver: trying /usr/lib/dri/swrast_dri.so libGL: Can't open configuration file /home/per/.drirc: No such file or directory. libGL: Can't open configuration file /home/per/.drirc: No such file or directory. 19 frames in 5.2 seconds = 3.670 FPS 18 frames in 5.0 seconds = 3.595 FPS 19 frames in 5.2 seconds = 3.671 FPS 19 frames in 5.2 seconds = 3.665 FPS
I noted that Mesa can't be build with DRI and Xlib-GLX: running configure on Mesa 10.0.1 sources, I get: configure: error: DRI and Xlib-GLX cannot be built together
Maybe your 13.1 machine has some old libraries around?
I don't think so, it's a fresh 13.1 install. -- Per Jessen, Zürich (15.4°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Per Jessen wrote:
Linda Walsh wrote:
Per Jessen wrote:
Running "ssh -X <remote> glxgears" works for me from a 12.3 onto a 13.1 system. I get about 4fps over wifi.
----
I get > ssh -X ishtar glxgears libGL error: failed to load driver: swrast
I had a failure to load i965:
BTW, this is with 13.1, not -factory. It has Mesa-9.2.3-61.9.1.i586 which contains swrast_dri.so. -- Per Jessen, Zürich (14.2°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 18 March 2014 20:41:43 Per Jessen wrote:
Per Jessen wrote:
Linda Walsh wrote:
Per Jessen wrote:
Running "ssh -X <remote> glxgears" works for me from a 12.3 onto a 13.1 system. I get about 4fps over wifi.
----
I get > ssh -X ishtar glxgears libGL error: failed to load driver: swrast
I had a failure to load i965: BTW, this is with 13.1, not -factory.
It has Mesa-9.2.3-61.9.1.i586 which contains swrast_dri.so.
You could have run strace -efile glxgears so see whats this error message is about. If you did, you would have seen that loading of the driver in the updates directory fails and the subsequent load of the driver from /usr/lib{64}/dri/ succeeds: ---- open("/usr/lib64/dri/updates/tls/swrast_dri.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib64/dri/updates/swrast_dri.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) libGL error: dlopen /usr/lib64/dri/updates/swrast_dri.so failed (/usr/lib64/dri/updates/swrast_dri.so: cannot open shared object file: No such file or directory) open("/usr/lib64/dri/tls/swrast_dri.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib64/dri/swrast_dri.so", O_RDONLY|O_CLOEXEC) = 4 ---- Everything is exactly working as expected, so can please everyone stop whining? Regards, Stefan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2014-03-18 22:26, Stefan Brüns wrote:
Everything is exactly working as expected, so can please everyone stop whining?
No, sir, it is not. Here, it only works if both machines have Intel graphics. It fails completely if one of the two machines is running the Nvidia proprietary driver. Please read the entire thread and don't jump to early conclusions. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 2014-03-18 11:59, Per Jessen wrote:
You joker!
That's because glx is configured to go around 'X' and directly to localhost...so of course ssh'ing into your own machine would work (providing your own machine can run glx)...
Running "ssh -X <remote> glxgears" works for me from a 12.3 onto a 13.1 system. I get about 4fps over wifi.
It doesn't here. cer@minas-tirith:~> glxgears libGL error: failed to load driver: swrast libGL error: Try again with LIBGL_DEBUG=verbose for more details. Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 18548 frames in 10.6 seconds = 1745.512 FPS XIO: fatal IO error 11 (Resource temporarily unavailable) on X server "localhost:10.0" after 40178 requests (834 known processed) with 0 events remaining. cer@minas-tirith:~> I get the graphics, but the wheels do not turn at all. Local machine has Nvidia graphics and driver, remote has Intel. Both run 13.1. Doing the reverse, there is no error message from libGL, but the wheels do not turn either, although it reports an absurdly high FPS, rate. Then I also get the same XIO error. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Tuesday 18 March 2014 12:47:59 Carlos E. R. wrote:
On 2014-03-18 11:59, Per Jessen wrote:
You joker!
That's because glx is configured to go around 'X' and directly to localhost...so of course ssh'ing into your own machine would work (providing your own machine can run glx)...
Running "ssh -X <remote> glxgears" works for me from a 12.3 onto a 13.1 system. I get about 4fps over wifi.
It doesn't here.
cer@minas-tirith:~> glxgears libGL error: failed to load driver: swrast libGL error: Try again with LIBGL_DEBUG=verbose for more details. Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 18548 frames in 10.6 seconds = 1745.512 FPS XIO: fatal IO error 11 (Resource temporarily unavailable) on X server "localhost:10.0" after 40178 requests (834 known processed) with 0 events remaining. cer@minas-tirith:~>
I get the graphics, but the wheels do not turn at all.
Stroboscope effect. Use the cursor keys to change the camera viewpoint ...
Local machine has Nvidia graphics and driver, remote has Intel. Both run 13.1.
Doing the reverse, there is no error message from libGL, but the wheels do not turn either, although it reports an absurdly high FPS, rate. Then I also get the same XIO error.
The XIO error happens when you close the window, nothing abnormal here ... Regards, Stefan
On 2014-03-18 22:28, Stefan Brüns wrote:
On Tuesday 18 March 2014 12:47:59 Carlos E. R. wrote:
Running "ssh -X <remote> glxgears" works for me from a 12.3 onto a 13.1 system. I get about 4fps over wifi.
It doesn't here.
I get the graphics, but the wheels do not turn at all.
Stroboscope effect.
Use the cursor keys to change the camera viewpoint ...
No, not at all. There is no network traffic.
The XIO error happens when you close the window, nothing abnormal here ...
Ak, ok. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Per Jessen wrote:
Running "ssh -X <remote> glxgears" works for me from a 12.3 onto a 13.1 system. I get about 4fps over wifi.
Try running a remote desktop via XDMCP. It hasn't worked since openSUSE 11.4. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 18 March 2014 08:15:32 James Knott wrote:
Per Jessen wrote:
Running "ssh -X <remote> glxgears" works for me from a 12.3 onto a 13.1 system. I get about 4fps over wifi.
Try running a remote desktop via XDMCP. It hasn't worked since openSUSE 11.4.
It does work. Tested 12.1, 12.2, 12.3, 13.1. Gnome 3 is slow as hell, but KDE 4 works fine, even kwins OpenGL compositing works. Regards, Stefan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Stefan Br���������������������������������� wrote:
On Tuesday 18 March 2014 08:15:32 James Knott wrote:
Per Jessen wrote:
Running "ssh -X <remote> glxgears" works for me from a 12.3 onto a 13.1 system. I get about 4fps over wifi. Try running a remote desktop via XDMCP. It hasn't worked since openSUSE 11.4.
It does work. Tested 12.1, 12.2, 12.3, 13.1.
It works on some hardware/sw configs, but hasn't been reliably reproduced by people who used it successfully before, and had it break. There is a difference. Please don't assume your experience is "universal". The fact that previous users had it break -- have tried to get it to work again (multiple times), and had no progress indicates *something broke*. It may be a previous configuration file that was made incompat by some new update that doesn't happen on a fresh install, I don't know. Whatever it was, it wasn't handled "seemlessly". I'm well aware of the "it works for me" quality standard.... but that it doesn't work for some segment of users should be given more consideration. Stop blaming the user for everything. Computers were to be built to be *user-friendly*. How can people build user-friendly interfaces, when they themselves are user-hostile? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 03/18/2014 05:56 PM, Linda Walsh wrote:
Stefan Br���������������������������������� wrote:
On Tuesday 18 March 2014 08:15:32 James Knott wrote:
Per Jessen wrote:
Running "ssh -X <remote> glxgears" works for me from a 12.3 onto a 13.1 system. I get about 4fps over wifi. Try running a remote desktop via XDMCP. It hasn't worked since openSUSE 11.4.
It does work. Tested 12.1, 12.2, 12.3, 13.1.
It works on some hardware/sw configs, but hasn't been reliably reproduced by people who used it successfully before, and had it break.
There is a difference.
Please don't assume your experience is "universal".
The fact that previous users had it break -- have tried to get it to work again (multiple times), and had no progress indicates *something broke*.
It may be a previous configuration file that was made incompat by some new update that doesn't happen on a fresh install, I don't know. Whatever it was, it wasn't handled "seemlessly".
I'm well aware of the "it works for me" quality standard.... but that it doesn't work for some segment of users should be given more consideration. Stop blaming the user for everything. Computers were to be built to be *user-friendly*. How can people build user-friendly interfaces, when they themselves are user-hostile?
ssh -X rr-iii glxgears libGL error: failed to load driver: i965 libGL error: Try again with LIBGL_DEBUG=verbose for more details. 118 frames in 5.0 seconds = 23.368 FPS XIO: fatal IO error 11 (Resource temporarily unavailable) on X server "localhost:10.0" after 546 requests (546 known processed) with 0 events remaining. It worked here, across the internet. I also run thunderbird this way -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Bruce Ferrell wrote:
ssh -X rr-iii glxgears libGL error: failed to load driver: i965 libGL error: Try again with LIBGL_DEBUG=verbose for more details. 118 frames in 5.0 seconds = 23.368 FPS XIO: fatal IO error 11 (Resource temporarily unavailable) on X server "localhost:10.0" after 546 requests (546 known processed) with 0 events remaining.
It worked here, across the internet. I also run thunderbird this way
Your thunderbird uses OpenGL? Mine doesn't. ;-(.... I can run firefox and mozilla remotely... almost reasonable speed, they don't generate the same messages nor operate at 8FPS... It's the Remote OpenGL that doesn't work. Many desktops use OpenGL for the various effects -- transparency, motion, among others. I can still run most individual X programs, though with 13.1 many of them no longer save settings and give error messages to the screen because they can't hook to a session bus -- how is that even supposed to work with a remote login? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Stefan Brüns wrote:
Try running a remote desktop via XDMCP. It hasn't worked since openSUSE
11.4. It does work. Tested 12.1, 12.2, 12.3, 13.1.
Gnome 3 is slow as hell, but KDE 4 works fine, even kwins OpenGL compositing works.
How are you starting the remote desktop? When I go switch user > remote login, no systems show up in the list, not even the computer I'm doing it on. At the moment, I have a ThinkPad and a desktop, with NVidia video card. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2014-03-18 11:49, Linda Walsh wrote:
Jan Engelhardt wrote:
On Tuesday 2014-03-18 09:43, Linda Walsh wrote:
When the dri drivers went into the X server, the removed the Xgl (or was it Xglx) extension that allowed OpenGL to be encapsulated in X.
Did they? `ssh -Y localhost glxgears` still does its job (in 13.1).
That's because glx is configured to go around 'X' and directly to localhost...so of course ssh'ing into your own machine would work (providing your own machine can run glx)...
So I just pick another fucking host then,-- it still works and I get chugging gears. 12:13 ares08:~ > LIBGL_DEBUG=verbose glxgears libGL: OpenDriver: trying /usr/lib64/dri/updates/tls/i915_dri.so libGL: OpenDriver: trying /usr/lib64/dri/updates/i915_dri.so libGL error: dlopen /usr/lib64/dri/updates/i915_dri.so failed (/usr/lib64/dri/updates/i915_dri.so: cannot open shared object file: No such file or directory) libGL: OpenDriver: trying /usr/lib64/dri/tls/i915_dri.so libGL: OpenDriver: trying /usr/lib64/dri/i915_dri.so libGL error: failed to open drm device: No such file or directory libGL error: failed to load driver: i915 libGL: OpenDriver: trying /usr/lib64/dri/updates/tls/swrast_dri.so libGL: OpenDriver: trying /usr/lib64/dri/updates/swrast_dri.so libGL error: dlopen /usr/lib64/dri/updates/swrast_dri.so failed (/usr/lib64/dri/updates/swrast_dri.so: cannot open shared object file: No such file or directory) libGL: OpenDriver: trying /usr/lib64/dri/tls/swrast_dri.so libGL: OpenDriver: trying /usr/lib64/dri/swrast_dri.so libGL: Can't open configuration file /home/jengelh/.drirc: No such file or directory. libGL: Can't open configuration file /home/jengelh/.drirc: No such file or directory. 42 frames in 5.0 seconds = 8.368 FPS 41 frames in 5.1 seconds = 8.086 FPS (and pulls down about 27 Mbit/s over Ethernet) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2014-03-18 12:14, Jan Engelhardt wrote:
So I just pick another fucking host then,-- it still works and I get chugging gears.
They do if both machines have an Intel graphics, but not if one is Nvidia with proprietary driver. Someone could try with the Nouveau driver, ATI, etc... I saw the "i915_dri.so" on your post, so just tried from one laptop to another, very old one, and it works. 15 FPS, 6 or 7 MB/s. With the XIO error at the end. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2014-03-18 12:14, Jan Engelhardt wrote:
So I just pick another fucking host then,-- it still works and I get chugging gears.
They do if both machines have an Intel graphics, but not if one is Nvidia with proprietary driver. Someone could try with the Nouveau driver, ATI, etc...
Are you saying you need like-for-like drivers now? That seems hard to imagine. I would note, the Nvidia OpenGL interface seems to be following the standard as per: http://en.wikipedia.org/wiki/OpenGL. I don't see an official extension named "texture from pixmap" on the official feature list (but that doesn't mean I'm not missing it)... Maybe the problem is the way it is done Xorg on linux is with an unofficial extension? Just guessing outloud I suppose at this point... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2014-03-18 13:20, Linda Walsh wrote:
Carlos E. R. wrote:
On 2014-03-18 12:14, Jan Engelhardt wrote:
So I just pick another fucking host then,-- it still works and I get chugging gears.
They do if both machines have an Intel graphics, but not if one is Nvidia with proprietary driver. Someone could try with the Nouveau driver, ATI, etc...
Are you saying you need like-for-like drivers now? That seems hard to imagine. I would note, the Nvidia OpenGL interface seems to be following the standard as per: http://en.wikipedia.org/wiki/OpenGL.
Sorry, I got lost here. I only say that I tried glxgears between two laptop with different Intel graphics hardware, and it worked. But between those same laptops and the desktop, which at the moment runs the Nvidia proprietary driver, does not work, in any direction. So I say that someone with nvidia hardware using the open driver nouveau could try the same test and see if it works. The more hardware/driver combinations we test, better for determining which pattern work. Maybe it is the proprietary driver that is the problem. Maybe not, and the hardware has to be similar (intel-intel, not nvidia-intel). -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Jan Engelhardt wrote:
So I just pick another fucking host then,-- it still works and I get chugging gears.
Ooops, sorry, thought you were joking the 1st time. No offense intended...
12:13 ares08:~ > LIBGL_DEBUG=verbose glxgears libGL: OpenDriver: trying /usr/lib64/dri/updates/i915_dri.so libGL error: dlopen /usr/lib64/dri/updates/i915_dri.so failed (/usr/lib64/dri/updates/i915_dri.so: cannot open shared object file: No such file or directory) libGL: OpenDriver: trying /usr/lib64/dri/i915_dri.so libGL error: failed to open drm device: No such file or directory libGL error: failed to load driver: i915 libGL: OpenDriver: trying /usr/lib64/dri/updates/tls/swrast_dri.so libGL: OpenDriver: trying /usr/lib64/dri/updates/swrast_dri.so libGL error: dlopen /usr/lib64/dri/updates/swrast_dri.so failed (/usr/lib64/dri/updates/swrast_dri.so: cannot open shared object file: No such file or directory) libGL: OpenDriver: trying /usr/lib64/dri/tls/swrast_dri.so libGL: OpenDriver: trying /usr/lib64/dri/swrast_dri.so
---- The thing is -- on my server machine, I have those libraries present in those locations. Yet it claims not to be able to find them. ???
42 frames in 5.0 seconds = 8.368 FPS 41 frames in 5.1 seconds = 8.086 FPS
(and pulls down about 27 Mbit/s over Ethernet)
And your gears turn?? I think my window didn't init correctly (tried it via cygwin ssh), but with SecureCRT ssh (not sure why that would make a difference, I get a picture of the gears, but no motion, THOUGH!, I do see my FRAPS benchmark tool that shows frame rates in the corner of a directX/openGL window -- and it is showing 30. So it really is like it is almost working, but ... reading this didn't give me much hope (wikipedia under Xgl): On January 2, 2006 most [2], the source to Xgl was re-opened to the public,[3][4] and included in freedesktop.org, along with major restructuring to allow a wider range of supported display drivers. X server backends used by Xgl include Xglx and Xegl. In February 2006 the server gained wide publicity after a public display where the **Novell desktop** team demonstrated a desktop using Xgl with several visual effects such as translucent windows and a rotating 3D desktop. ... yay novell! Then came AIGLX: ---(under AIGLX): Accelerated Indirect GLX ("AIGLX") is an open source project founded by Red Hat and the Fedora community, to allow accelerated indirect GLX rendering capabilities to the X.Org Server and DRI drivers. This allows remote X clients to get fully hardware accelerated rendering over the GLX protocol; coincidentally, this development was required for OpenGL compositing window managers to function with hardware acceleration. ...However,.... ==Relationship to Xgl==(also under AIGLX article) Although the AIGLX project has features similar to Xgl, it was not intended to be a competing product. ...[however, despite code sharing between AIGLX] and Xgl, Xgl was removed from the X Server on June 12, 2008. --Of note was a comment: Glitz – was superseded by AIGLX and I still have some glitz config files sitting around that don't seem very current. But I have a feeling that was the last it worked. Also of interest -- glx info DOES read what type of video card I hve and it's GLX options... but then it seems to ignore that and go on to load swrast...so, not sure what it is doing. It looked too me like, at the very least, platform interoperability was now a problem and not one before -- I get the same errors about not beign able to open drivers when I tried xrdp and xdmcp which other people have not been able to get get to work either. So it looks like the performance dropped from the previous (though I think my earlier testing was done on a 1Gb hardwire -- quite a bit different from a WiFi connection, so that might explain most of the diff. Yet still no motion on my end... Hmmm... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2014-03-18 12:58, Linda Walsh wrote:
42 frames in 5.0 seconds = 8.368 FPS 41 frames in 5.1 seconds = 8.086 FPS
(and pulls down about 27 Mbit/s over Ethernet)
And your gears turn??
Well, if you can still call it "turn" with the stuttering that is 8 fps. Shrinking the window leads to increased fps and with about 16-20fps, you have the minimum smoothness the eye needs. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 18.03.2014 13:17, schrieb Jan Engelhardt:
Well, if you can still call it "turn" with the stuttering that is 8 fps. Shrinking the window leads to increased fps and with about 16-20fps, you have the minimum smoothness the eye needs.
But that does not sound like hardware accelerated like you would expect it to be. It's just software rendered into a frame buffer on the server side and then transferred as bitmaps to the displaying machine. I seem to remember when I tried this last (> 5 years ago), the rendering was actually done on the hw-accel of the displaying machine, and I got decent FPS. Not as fast as local DRI rendering, but certainly more than a few FPS. And the FPS was not really different with different window sizes. So probably Linda has a point and discovered some real breakage. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 2014-03-19 11:33, Stefan Seyfried wrote:
Am 18.03.2014 13:17, schrieb Jan Engelhardt:
Well, if you can still call it "turn" with the stuttering that is 8 fps. Shrinking the window leads to increased fps and with about 16-20fps, you have the minimum smoothness the eye needs.
But that does not sound like hardware accelerated like you would expect it to be.
I never claimed it would be. After all, transporting the bitmaps out of the render machine is the bottleneck, especially with latent Internet links and stream-protocolled ssh-tunneled X11 protocol. The only extra icing to get even worse performance is - probably - to go to a pre-XCB implementation.
It's just software rendered into a frame buffer on the server side and then transferred as bitmaps to the displaying machine. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, LIBGL_ALWAYS_INDIRECT=1 glxgears might be worth a try. Most probably the llvm based llvmpipe (swrast) counts as direct rendering on the same machine where the application is running and is thus prefered to AIGLX. Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2014-03-19 13:58, Brüns, Stefan wrote:
Hi,
LIBGL_ALWAYS_INDIRECT=1 glxgears might be worth a try.
cer@AmonLanc:~> LIBGL_ALWAYS_INDIRECT=1 glxgears Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 21039 frames in 11.8 seconds = 1784.601 FPS XIO: fatal IO error 11 (Resource temporarily unavailable) on X server "localhost:10.0" after 44182 requests (33 known processed) with 0 events remaining. cer@AmonLanc:~> No wheel movement, no network transmission. Sever has Intel graphics, client Nvidia with proprietary driver. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2014-03-19 13:58, Br�ns, Stefan wrote:
Hi,
LIBGL_ALWAYS_INDIRECT=1 glxgears might be worth a try.
cer@AmonLanc:~> LIBGL_ALWAYS_INDIRECT=1 glxgears Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 21039 frames in 11.8 seconds = 1784.601 FPS XIO: fatal IO error 11 (Resource temporarily unavailable) on X server "localhost:10.0" after 44182 requests (33 known processed) with 0 events remaining. cer@AmonLanc:~>
No wheel movement, no network transmission. Sever has Intel graphics, client Nvidia with proprietary driver.
Similar here...first got: Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 45623 frames in 6.4 seconds = 7166.903 FPS 834 frames in 27.4 seconds = 30.428 FPS 822 frames in 28.8 seconds = 28.542 FPS ---- With all X-window response degraded (Xserver process was peg'ed@100%cpu), virtually no network traffic -- dropped from a norm of 200-400KB/s down to between 1KB-80KB/s. Note, While my monitor is running at about 30FPS, no way is it capable of 7166FPS! The initial gears displayed in the window, but no turning. If I close the X-window instead of control-C in the starting window, I also see: XIO: fatal IO error 11 (Resource temporarily unavailable) on X server "athenae.hs.tlinx.org:0" after 91313 requests (33 known processed) with 0 events remaining. --- But that's understandable as the sending program is reporting it's resource (the window closed on my server) is 'temporarily unavailable'... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 19 March 2014 17:31:22 Carlos E. R. wrote:
On 2014-03-19 13:58, Brüns, Stefan wrote:
Hi,
LIBGL_ALWAYS_INDIRECT=1 glxgears might be worth a try.
cer@AmonLanc:~> LIBGL_ALWAYS_INDIRECT=1 glxgears Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 21039 frames in 11.8 seconds = 1784.601 FPS XIO: fatal IO error 11 (Resource temporarily unavailable) on X server "localhost:10.0" after 44182 requests (33 known processed) with 0 events remaining. cer@AmonLanc:~>
No wheel movement, no network transmission. Sever has Intel graphics, client Nvidia with proprietary driver.
Which libGL is being used? $> ldd /usr/bin/glxgears | grep GL Whats the output of $> rpm -qf /usr/lib/libGL.so* on the client? Is it Mesa or NVidia? (I assume client and server is X terminology, i.e. glxgears is (running on) the client and the server is the display terminal). Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019
On 2014-03-20 00:11, Stefan Brüns wrote:
On Wednesday 19 March 2014 17:31:22 Carlos E. R. wrote:
No wheel movement, no network transmission. Sever has Intel graphics, client Nvidia with proprietary driver.
Which libGL is being used? $> ldd /usr/bin/glxgears | grep GL
Remote: cer@minas-tirith:~> ldd /usr/bin/glxgears | grep GL libGL.so.1 => /usr/lib64/libGL.so.1 (0x00007f7d5ddc8000) cer@minas-tirith:~> rpm -qf /usr/lib64/libGL.so.1 Mesa-libGL1-9.2.3-61.9.1.x86_64 cer@minas-tirith:~> Local: cer@Telcontar:~> ldd /usr/bin/glxgears | grep GL libGL.so.1 => /usr/X11R6/lib64/libGL.so.1 (0x00007f02fb5bb000) cer@Telcontar:~> rpm -qf /usr/X11R6/lib64/libGL.so.1 nvidia-glG03-331.49-29.1.x86_64 cer@Telcontar:~>
(I assume client and server is X terminology, i.e. glxgears is (running on) the client and the server is the display terminal).
To avoid confusions, I refer to remote and local machine instead :-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Stefan Br���������������������������������� wrote:
Which libGL is being used? $> ldd /usr/bin/glxgears | grep GL
Whats the output of $> rpm -qf /usr/lib/libGL.so* on the client?
Is it Mesa or NVidia?
(I assume client and server is X terminology, i.e. glxgears is (running on) the client and the server is the display terminal).
ldd /usr/bin/glxgears|grep GL
I try to use that when talking about 'X', as my display server for desktops is separate from my disk server (which is the client for the display server), which serves just about everything for the display server -- except graphics and windows apps which can run natively on the display client. ---- libGL.so.1 => /usr/lib64/libGL.so.1 (0x00007f538975d000) Ishtar> rpm -qf /usr/lib/libGL.so* error: file /usr/lib/libGL.so*: No such file or directory Ishtar> rpm -qf /usr/lib64/libGL.so* Mesa-libGL-devel-9.2.3-61.9.1.x86_64 Mesa-libGL1-9.2.3-61.9.1.x86_64 Mesa-libGL1-9.2.3-61.9.1.x86_64 Mesa-libGL1-9.2.3-61.9.1.x86_64 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Mar 19, 2014 at 8:11 PM, Stefan Brüns
On Wednesday 19 March 2014 17:31:22 Carlos E. R. wrote:
On 2014-03-19 13:58, Brüns, Stefan wrote:
Hi,
LIBGL_ALWAYS_INDIRECT=1 glxgears might be worth a try.
cer@AmonLanc:~> LIBGL_ALWAYS_INDIRECT=1 glxgears Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 21039 frames in 11.8 seconds = 1784.601 FPS XIO: fatal IO error 11 (Resource temporarily unavailable) on X server "localhost:10.0" after 44182 requests (33 known processed) with 0 events remaining. cer@AmonLanc:~>
No wheel movement, no network transmission. Sever has Intel graphics, client Nvidia with proprietary driver.
Which libGL is being used? $> ldd /usr/bin/glxgears | grep GL
Whats the output of $> rpm -qf /usr/lib/libGL.so* on the client?
Is it Mesa or NVidia?
Here I get on the client (in X terms): ~$ dpkg -l | grep -i libgl ii libgl1-mesa-glx 7.0.3-7 A free implementation of the OpenGL API -- GLX runtime ii libglib2.0-0 2.16.6-3 The GLib library of C routines ii libglib2.0-data 2.16.6-3 Common files for GLib library ii libglib2.0-dev 2.16.6-3 Development files for the GLib library ii libglu1-mesa 7.0.3-7 The OpenGL utility library (GLU) ~$ ldd /usr/bin/glxgears | grep GL libGL.so.1 => /usr/lib/libGL.so.1 (0xb7693000) Server (in X terms) is openSUSE 13.1 ~> rpm -qf /usr/lib64/libGL.so* Mesa-libGL-devel-9.2.3-61.9.1.x86_64 Mesa-libGL1-9.2.3-61.9.1.x86_64 Mesa-libGL1-9.2.3-61.9.1.x86_64 Mesa-libGL1-9.2.3-61.9.1.x86_64 ~> ldd /usr/bin/glxgears | grep GL libGL.so.1 => /usr/lib64/libGL.so.1 (0x00007fa58a018000) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (11)
-
Bruce Ferrell -
Brüns, Stefan -
Carlos E. R. -
Claudio Freire -
James Knott -
Jan Engelhardt -
L.A. Walsh -
Linda Walsh
-
Per Jessen -
Stefan Brüns
-
Stefan Seyfried