OpenGL over X11/SSH

[Andrea Venturoli]

Hello.

I apoligize if this is a FAQ, but I could not find any useful pointer.


I'm used to connecting via ssh to a couple of "heavy duty" servers on my
LAN; I've got X11 forward working and in fact I usually run emacs,
xterm, sometimes even FireFox.

Now I need to try an OpenGL-based program, but I'm not able to get it right.



> % glxinfo
> name of display: localhost:11.0
> libGL error: failed to open drm device: No such file or directory
> libGL error: failed to load driver: r600
> libGL error: unable to load driver: swrast_dri.so
> libGL error: failed to load driver: swrast
> X Error of failed request: GLXBadContext
> Major opcode of failed request: 154 (GLX)
> Minor opcode of failed request: 6 (X_GLXIsDirect)
> Serial number of failed request: 46
> Current serial number in output stream: 45



AFAICT this should work, albeit without hardware acceleration, which is
fine to me since this is only going to be a test.



Any help?

bye & Thanks
av.
_______________________________________________
freebsd-...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questi...@freebsd.org"

[Polytropon]

On Wed, 21 Sep 2016 17:50:53 +0200, Andrea Venturoli wrote:
> I'm used to connecting via ssh to a couple of "heavy duty" servers on my
> LAN; I've got X11 forward working and in fact I usually run emacs,
> xterm, sometimes even FireFox.
>
> Now I need to try an OpenGL-based program, but I'm not able to get it right.
>
>
>
> > % glxinfo
> > name of display: localhost:11.0
> > libGL error: failed to open drm device: No such file or directory
> > libGL error: failed to load driver: r600
> > libGL error: unable to load driver: swrast_dri.so
> > libGL error: failed to load driver: swrast
> > X Error of failed request: GLXBadContext
> > Major opcode of failed request: 154 (GLX)
> > Minor opcode of failed request: 6 (X_GLXIsDirect)
> > Serial number of failed request: 46
> > Current serial number in output stream: 45
>
>
>
> AFAICT this should work, albeit without hardware acceleration, which is
> fine to me since this is only going to be a test.

If I understand the messages correctly, the OpenGL output requires
direct rendering (DRM) instead of a software renderer. The DRM/DRI
task is being performed directly on the hardware the program is
running on and maybe cannot be redirected to a remote X system.
The somehow direct access to the hardware maybe cannot be tunneled
over X11/SSH. The messages indicate that the DRM device cannot be
found and the r600 (Radeon?) driver cannot be loaded. This is a
quire early error of libGL.

On the other hand, if you use software rendering, it _should_ work.



--
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...

[Andrea Venturoli]

On 09/22/16 05:17, Polytropon wrote:

> If I understand the messages correctly, the OpenGL output requires
> direct rendering (DRM) instead of a software renderer.

Ok, but why?
Is this a requirement an X client can impose?
An option in some port?
A sysctl?
...?

I see other programs giving the same message, but then proceed with
software rendering.

> The DRM/DRI
> task is being performed directly on the hardware the program is
> running on and maybe cannot be redirected to a remote X system.

Being a headless server, I don't think I've enabled DRI on this box... I
don't load any related kernel module and I don't even have an Xorg.conf.
BTW, I forgot to mention this is 10.3/amd64.

> The somehow direct access to the hardware maybe cannot be tunneled
> over X11/SSH.

Ok with this; I'd just like to avoid DRM/DRI at all.

> The messages indicate that the DRM device cannot be
> found and the r600 (Radeon?) driver cannot be loaded.

There is no Radeon card on the headless box; the CPU is an i5 (with
integrated GPU) and that's all.
I've got a Radeon on the client (i.e. where the X server runs), but does
this matter?

> This is a quire early error of libGL.

Sorry, I don't understand what you mean here.

> On the other hand, if you use software rendering, it _should_ work.

Exactly as I thought.
So the question is: how do I force software rendering?



bye & Thanks
av.

[Mehmet Erol Sanliturk]

On Wed, Sep 21, 2016 at 11:48 PM, Andrea Venturoli <m...@netfence.it> wrote:

> On 09/22/16 05:17, Polytropon wrote:
>
> If I understand the messages correctly, the OpenGL output requires
>> direct rendering (DRM) instead of a software renderer.
>>
>
> Ok, but why?
> Is this a requirement an X client can impose?
> An option in some port?
> A sysctl?
> ...?
>
> I see other programs giving the same message, but then proceed with
> software rendering.
>
>
>

Reason is the kind of writing and compilation of OpenGL programs :


There are two options :

( 1 ) Use graphics card hardware : This depends on graphics card related
libraries/features and
requires a graphics card having the used features

( 2 ) Without using graphics card hardware , means using software for
graphics computations.



Therefore , it is necessary to check the program to use with respect to
which features are used
and apply it with respect to these features .


If the program depends on graphics card hardware , and such a graphics card
does not exist , it will produce errors and stop or crash .


Mehmet Erol Sanliturk

> To unsubscribe, send any mail to "freebsd-questions-unsubscribe
> @freebsd.org"

[Polytropon]

On Thu, 22 Sep 2016 08:48:41 +0200, Andrea Venturoli wrote:
> On 09/22/16 05:17, Polytropon wrote:
>
> > If I understand the messages correctly, the OpenGL output requires
> > direct rendering (DRM) instead of a software renderer.
>
> Ok, but why?
> Is this a requirement an X client can impose?

Yes. The program has been explicitely constructed in a way
that it requires OpenGL "function calls" to actual hardware.
That is not something the "X server + client" model can
relay through networking, as far as I know. As I have never
actually tried to get OpenGL "through" SSH+X11, this is more
or less guesswork to me. :-)

> An option in some port?

Probably yes.



> A sysctl?

No. The system-side software parts involved are DRM/DRI
which are tightly coupled to the X11 system and the OpenGL
libraries in use.

> I see other programs giving the same message, but then proceed with
> software rendering.

That is quite possible if the program does not specify or
require hardware accelleration.

> > The DRM/DRI
> > task is being performed directly on the hardware the program is
> > running on and maybe cannot be redirected to a remote X system.
>
> Being a headless server, I don't think I've enabled DRI on this box... I
> don't load any related kernel module and I don't even have an Xorg.conf.

Without xorg.conf, loading the DRM/DRI components is probably
the default by now. Depending on the GPU in use, adding modules
to /boot/loader.conf _might_ be required. On a headless system
this is possible (if it contains a GPU), but probably won't
help if there is no local display.

> > The somehow direct access to the hardware maybe cannot be tunneled
> > over X11/SSH.
>
> Ok with this; I'd just like to avoid DRM/DRI at all.

It only makes sense for local displays.

> > The messages indicate that the DRM device cannot be
> > found and the r600 (Radeon?) driver cannot be loaded.
>
> There is no Radeon card on the headless box; the CPU is an i5 (with
> integrated GPU) and that's all.
> I've got a Radeon on the client (i.e. where the X server runs), but does
> this matter?

Maybe. If my guess is right and "r600" is related to that Radeon
card (client-side), the program seems to try to attach to it. Do
you have DRM/DRI enabled on your client where the local display
is being used?

> > This is a quire early error of libGL.
>
> Sorry, I don't understand what you mean here.

Typo. I wanted to state that the program which uses the OpenGL
library seems to quit at an early stage because the library is
not able to continue what it's doing quite early in the program.

Depending on the actual program, there are three things which
could happen:

1. The program quits with an error message.

2. The program uses software rendering (and maybe gets much
slower).

3. The program reacts in an unpredicatable way (program crash).

> > On the other hand, if you use software rendering, it _should_ work.
>
> Exactly as I thought.
> So the question is: how do I force software rendering?

If I remember my "OpenGL adventures" (many years ago) correctly,
the _program_ needs to be able to request software rendering. This
can be done by deactivating the OpenGL hardware accelleration at
compile time, or by an option - it depends on the program.

--
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...

[Andrea Venturoli]

On 09/22/16 09:32, Polytropon wrote:

>> An option in some port?
>
> Probably yes.

I checked graphics/libGL, but it has no options.
Any other hint?

> Without xorg.conf, loading the DRM/DRI components is probably
> the default by now.

Ok, but xorg.conf should be an X-server config file.
So I have no X-server where the client program runs.

> Maybe. If my guess is right and "r600" is related to that Radeon
> card (client-side), the program seems to try to attach to it. Do
> you have DRM/DRI enabled on your client where the local display
> is being used?

Yes: the client machine happily works in DRM/DRI mode with a Radeon.
I'd like to keep that, since local applications take advantage from it.

I'm wondering: since the error also mentions swrast and swrast_dri.so,
could I try to make it work this way? Where would I find them?

> If I remember my "OpenGL adventures" (many years ago) correctly,
> the _program_ needs to be able to request software rendering. This
> can be done by deactivating the OpenGL hardware accelleration at
> compile time, or by an option - it depends on the program.

The "program" has no such options: it uses graphics/togl, however.
There is no option in togl either :(



bye & Thanks
av.

[Shane Ambler]

On 22/09/2016 17:25, Andrea Venturoli wrote:
> On 09/22/16 09:32, Polytropon wrote:
>
>>> An option in some port?
>>
>> Probably yes.
>
> I checked graphics/libGL, but it has no options.
> Any other hint?

Not sure this will actually help but it may give a clue as to how to
patch the app you are trying to run.

A few days ago there was a commit to blender that enabled the use of
software opengl render on OSX when older cards are in place that don't
support the required openGL version.

https://developer.blender.org/rBe12f5b699d5a2eea045b584ebc7264bddcfb994d

I don't know much about GL programming but it sounds like the app can
choose if GL provides the required features (or gl version?) to run
which may include hardware acceleration, this appears to be decided at
the time the GLContext is created.

--
FreeBSD - the place to B...Software Developing

Shane Ambler

[Mehmet Erol Sanliturk]

On Thu, Sep 22, 2016 at 7:01 PM, Shane Ambler <Fre...@shaneware.biz> wrote:

> On 22/09/2016 17:25, Andrea Venturoli wrote:
>
>> On 09/22/16 09:32, Polytropon wrote:
>>
>> An option in some port?
>>>>
>>>
>>> Probably yes.
>>>
>>
>> I checked graphics/libGL, but it has no options.
>> Any other hint?
>>
>
> Not sure this will actually help but it may give a clue as to how to
> patch the app you are trying to run.
>
> A few days ago there was a commit to blender that enabled the use of
> software opengl render on OSX when older cards are in place that don't
> support the required openGL version.
>
> https://developer.blender.org/rBe12f5b699d5a2eea045b584ebc7264bddcfb994d
>
> I don't know much about GL programming but it sounds like the app can
> choose if GL provides the required features (or gl version?) to run
> which may include hardware acceleration, this appears to be decided at
> the time the GLContext is created.
>
> --
> FreeBSD - the place to B...Software Developing
>
> Shane Ambler
>
> _______________________________________________
>
>

For OpenGL programming the following can be done :


At the beginning , during starting OpenGL :

Check whether there is a graphics facility ( either a graphics card or a
suitable CPU combined with hardware enabled OpenGL processing ) :

If such a facility exists , use this facility by calling hardware based
OpenGL processing routines ( fast computations and displays ) ,
else call software enabled OpenGL processing routines instead of giving an
error message and stop or crash ( slow computations and displays ) .



This is also an addition to my previous message in this thread where I
forgot to mention above possibility .


If the above structure is used , the program will be suitable to be
executed in any computer conforming its range of CPU whether it has
hardware based OpenGL facility or not .


Mehmet Erol Sanliturk