Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 22 Sep 2016 09:32:25 +0200
From:      Polytropon <freebsd@edvax.de>
To:        Andrea Venturoli <ml@netfence.it>
Cc:        "freebsd-questions@freebsd.org" <freebsd-questions@freebsd.org>
Subject:   Re: OpenGL over X11/SSH
Message-ID:  <20160922093225.92c833cc.freebsd@edvax.de>
In-Reply-To: <15ee2107-8cdc-8d1a-4bb5-2765587453b0@netfence.it>
References:  <2deff892-7ac3-e3e2-92fe-27e95f089ea0@netfence.it> <20160922051741.5092ccae.freebsd@edvax.de> <15ee2107-8cdc-8d1a-4bb5-2765587453b0@netfence.it>

next in thread | previous in thread | raw e-mail | index | archive | help
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, ...



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160922093225.92c833cc.freebsd>